Reactor模型
了解了NIO多路复用后，就有必要再和大家说一下Reactor多路复用高性能I/O设计模式，Reactor本质上就是基于NIO多路复用机制提出的一个高性能IO设计模式，它的核心思想是把响应IO事件和业务处理进行分离，通过一个或者多个线程来处理IO事件，然后将就绪得到事件分发到业务处理handlers线程去异步非阻塞处理
Reactor模型有三个重要的组件：
Reactor ：将I/O事件发派给对应的Handler
Acceptor ：处理客户端连接请求
Handlers ：执行非阻塞读/写
这是最基本的单Reactor单线程模型（整体的I/O操作是由同一个线程完成的）。
其中Reactor线程，负责多路分离套接字，有新连接到来触发connect 事件之后，交由Acceptor进行处理，有IO读写事件之后交给hanlder 处理。
Acceptor主要任务就是构建handler ，在获取到和client相关的SocketChannel之后 ，绑定到相应的hanlder上，对应的SocketChannel有读写事件之后，基于racotor 分发,hanlder就可以处理了（所有的IO事件都绑定到selector上，有Reactor分发）
多线程单Reactor模型
单线程Reactor这种实现方式有存在着缺点，从实例代码中可以看出，handler的执行是串行的，如果其中一个handler处理线程阻塞将导致其他的业务处理阻塞。由于handler和reactor在同一个线程中的执行，这也将导致新的无法接收新的请求，我们做一个小实验：
在上述Reactor代码的DispatchHandler的run方法中，增加一个Thread.sleep()。
打开多个客户端窗口连接到Reactor Server端，其中一个窗口发送一个信息后被阻塞，另外一个窗口再发信息时由于前面的请求阻塞导致后续请求无法被处理。
为了解决这种问题，有人提出使用多线程的方式来处理业务，也就是在业务处理的地方加入线程池异步处理，将reactor和handler在不同的线程来执行
多线程多Reactor模型
在多线程单Reactor模型中，我们发现所有的I/O操作是由一个Reactor来完成，而Reactor运行在单个线程中，它需要处理包括Accept()/read()/write/connect操作，对于小容量的场景，影响不大。但是对于高负载、大并发或大数据量的应用场景时，容易成为瓶颈，主要原因如下：
一个NIO线程同时处理成百上千的链路，性能上无法支撑，即便NIO线程的CPU负荷达到100%，也无法满足海量消息的读取和发送；
当NIO线程负载过重之后，处理速度将变慢，这会导致大量客户端连接超时，超时之后往往会进行重发，这更加重了NIO线程的负载，最终会导致大量消息积压和处理超时，成为系统的性能瓶颈；
所以，我们还可以更进一步优化，引入多Reactor多线程模式，Main Reactor负责接收客户端的连接请求，然后把接收到的请求传递给SubReactor（其中subReactor可以有多个），具体的业务IO处理由SubReactor完成。
Multiple Reactors 模式通常也可以等同于 Master-Workers 模式，比如 Nginx 和 Memcached 等就是采用这种多线程模型，虽然不同的项目实现细节略有区别，但总体来说模式是一致的。
Acceptor，请求接收者，在实践时其职责类似服务器，并不真正负责连接请求的建立，而只将其请求委托 Main Reactor 线程池来实现，起到一个转发的作用。
Main Reactor，主 Reactor 线程组，主要负责连接事件，并将IO读写请求转发到 SubReactor 线程池。
Sub Reactor，Main Reactor 通常监听客户端连接后会将通道的读写转发到 Sub Reactor 线程池中一个线程(负载均衡)，负责数据的读写。在 NIO 中 通常注册通道的读(OP_READ)、写事件(OP_WRITE)。
