实用的网络模型

常见网络模型

几种实用模型

2.thread-per-connection
5.单线程 Reactor
8.Reactor + 线程池
9.one loop per thread
11.one loop per thread + 线程池

方案2：thread-per-connection

比方案1 process-per-connection 开销小，但程序伸缩性受到线程数限制，不适合短连接服务，连接一两百个还行，几千个的话对操作系统的 scheduler 恐怕是个不小的负担。

方案5：单线程 Reactor

这种方案的优点是由网络库搞定数据收发，程序只关心业务逻辑；缺点是：适合 IO 密集的应用，不太适合 CPU 密集的应用，因为较难发挥多核的威力。
此方案处理网络消息延迟可能略大于方案2，因为方案2直接一次read系统调用就能拿到请求数据，方案5要先poll再read，多了一次系统调用。

note：在使用非阻塞IO+事件驱动方式编程的时候，一定要注意避免在事件回调中执行耗时的操作，包括阻塞IO等，否则会影响程序响应。

方案8：Reactor + 线程池

全部IO工作交给一个reaction线程处理，而计算任务交给thread pool，如果计算任务彼此独立，而且 IO 的压力不大，那么这种方案是非常适用的。如果 IO 的压力比较大，一个 reactor 忙不过来，可以试试 multiple reactors 的方案 9。而且这种方案不用为每个请求创建线程，减少了开销。

方案9：one loop per thread

有一个 main reactor 负责 accept 连接，然后把连接挂在某个 sub reactor 中，这样该连接的所有操作都在那个 sub reactor 所处的线程中完成。多个连接可能被分派到多个线程中，以充分利用 CPU。sub reactor可以是一开始就创建的pool，根据CPU数据创建池子的大小，也就是线程数是固定的，这样程序的总体处理能力不会随连接数增加而下降。把多个连接分散到多个Reactor线程之后，小规模计算可以在当前IO线程完成并发回结果，从而降低延迟。

方案11：one loop per thread + 线程池（推荐）

把方案 8 和方案 9 混合，既使用多个 reactors 来处理 IO，又使用线程池来处理计算。这种方案适合既有突发 IO （利用多线程处理多个连接上的 IO），又有突发计算的应用（利用线程池把一个连接上的计算任务分配给多个线程去做），但这种方案资源利用率可能比方案9高，但延迟比方案9略大，因为多了进出poll的开销。

note:如果程序IO带宽较小，计算量较大，而且对延迟不敏感，可以把计算放到thread pool中，也可以只用一个event loop。

参考

陈硕blog: 链接
reactor的介绍: 链接