#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。

补充一下。

1）从数学概念上来看。类是一种限制，或者说一种集合。

它定义了两个要素：一个是允许取值的集合，一个是允许参与的运算。例如int类型在Java中既定义了介于-2的31次方和2的31次方 – 1之间的整数集合，也隐式限制了该集合上的整数所能进行的运算。

如果我们需要将 2.add(2)的结果得到“22”，则需要将它转换为另一个String类。

从这个意义上来说，类型本身对类型行为就存在约束。因此Linus说：“Bad programmers worry about the code. Good programmers worry about data structures and their relationships.”。

2）以OOP的视角来看，code即类的method，data structures and their relationships即类的attributes，类的耦合关系。 从类的实例化，多态，继承、组合等各种类的关系来看类，都有一翻解释，话题太大。

3）从现实和自然语言的视角来看，类是因为相似事物的属性，而混杂随意的概念集合。和编程中的严格的数学约束虽然有相通的地方，实际上则是貌合神离。