【网络IO】细说网络IO模型【三】
简介：
前两篇已经叫整理了常见的网络io原理与模型，本篇整理基于IO模型构造的更复杂的IO模型。如Redis底层IO模型、Netty底层IO模型等
网络IO相关文章
Reactor模型
- Reactor模型本质上为IO多路复用模型 + 池化技术结合IO多路复用负责统一监听事件，收到事件后派发给资源池中的某个线程或进程。
- 其中根据Reacotr的数量和资源池中资源的数量和类型存在三种实现方案
- 单Reactor + 单进程/单线程
- 单Reactor + 多线程
- 多Reactor + 多进程/多线程
- Reactor模型里重要的概念
- Reactor：类似NIO编程中的Selector，负责I/O事件的派发；
- Acceptor：NIO中接收到事件后，处理连接的那个分支逻辑；
- Handler：消息读写处理等操作类。
单Reactor + 单进程 | 单线程
- Reactor 对象通过 select 监控连接事件，收到事件后通过 dispatch 进行分发。
- 如果是连接建立的事件，则由 Acceptor 处理，Acceptor 通过 accept 接受连接，并创建一个 Handler 来处理连接后续的各种事件。
- 如果不是连接建立事件，则 Reactor 会调用连接对应的 Handler（第 2 步中创建的Handler）来进行响应。Handler 会完成 read-> 处理 ->send 的完整业务流程。
- 这种优点很明显，就是简单，不用考虑进程间通信、线程安全、资源竞争等问题。但是也有自身的局限性，就是无法利用多核资源，只适用于业务处理非常快速的场景，Redis就是采用的这种方案。
单Reactor + 多线程
- 与单Reactor单线程方案相比，不同的是：Handler只负责响应事件，并不负责处理事件，Handler读取数据后会发送给Processor进行处理。Processor在子线程中完成业务处理，然后将结果发送给Handler。由Handler将结果返回给client。
- 没有列出单Reactor + 多进程方案，主要因为如果采用多进程，就要考虑进程间通信的问题，比如子进程处理完成后需要通知父进程将结果返回给对应的client，处理比较复杂。但多线程之间数据是共享的，复杂度相对比较低。
- 另外，这种方案下，主线程承担了所有的事件监听和响应。瞬间高并发时可能会成为性能瓶颈。这时就需要多Reactor的方案了。
多Reactor + 多线程 | 多进程
- 父进程中 mainReactor 对象通过 select 监控连接建立事件，收到事件后通过 Acceptor接收，将新的连接分配给某个子进程。
- 子进程的 subReactor 将 mainReactor 分配的连接加入连接队列进行监听，并创建一个Handler 用于处理连接的各种事件。
- 当有新的事件发生时，subReactor 会调用连接对应的 Handler（即第 2 步中创建的Handler）来进行响应。
- Handler 完成 read→处理→send 的完整业务流程。
- 目前著名的开源系统 Nginx 采用的是多 Reactor 多进程，采用多 Reactor 多线程的实现有Memcache 和 Netty。不过需要注意的是 Nginx 中与上图中的方案稍有差异，具体表现在主进程中并没有mainReactor来建立连接，而是由子进程中的subReactor建立。
