多谢捧场，估计一周一更

#19楼 @gwotzehsing 需要一个request队列来解决这个磁盘瓶颈的问题。

并且监控队列的长度和“清request”的速度，观察系统的性能压力。

队列多了以后，平衡队列的数量来保证CPU的利用率。之后通过调度器来控制队列的依赖顺序及优先级，最后通过限制每个队列的长度，来控制延迟和吞吐量之间的关系。

IO优化都是这么一套玩法，应该没啥。

#5楼 @linsk 哈哈哈哈哈哈多谢！

#7楼 @ladrift 哇，可以啊，不过对水平有要求，简历也可以发到邮箱哟：liusihao@quantmi.com

#2楼 @heliang7 之前在循礼门，招人后会搬去光谷广场或广埠屯

所谓人才市场，由微观宏观两块组成。 1）宏观上是市场供需，供大于需要求要多高就能提多高，比如投行业和咨询业，其实实际工作并没有那么难；需求大于供给的时候，LZ这样刚入门的水平已经够用了，而在成都的Ruby圈，我相信是后者。

2）微观上是招聘者的具体需求，我一个朋友，前端水平可能和LZ差不多，但一个很不错的企业要了他。为什么？因为他们公司有专职前端，只要求后端水平到达一定程度就够了。这时候针对应聘公司及同类公司的业务介绍、套瓷公司员工就能得出他们当前项目的具体需求，差什么补什么即可，然后你一上来就能做，还是拿的实习工资，公司岂会不要你，并不需要像楼里面的朋友们要求那么严格和全面。

这两点是人才市场的基本规律，楼主如果理解了，相信以小搏大不是难事。求职，本质上也是个经济学问题，供需越接近完美的平衡就越成功——找到最需要自己又最能发挥自己价值的地方；毕竟每个人都有他的局限之处，并非所有团队都那么求全责备。

补充下，JS以前非内建的继承和模拟类的方法，https://ruby-china.org/topics/17423

赞一个！

发布订阅模式的使用原因是：实际上是将发布方的callback逻辑抽离出来，单独作为一个Service Object（即订阅端）。逻辑的信息量并没有变，但将这部分信息量分化出来以降低复杂度。

这里的ClientListener，其实是一个总callback类，而到底需要callback哪一个，则由ClientListener方法决定，而非发布方决定。

#6楼 @Rei 赞，Show本身就和ActiveRecord之类的类天然有耦合性，在这里类的主要作用变异为了组织信息，而非组织数据。与OOP中类的概念天然背道而驰。

P.S. 组织信息所用的类必须是singleton class。