Reactor反应器模式
反应器模式由Reactor反应器线程、Handlers处理器两大角色组成：
- Reactor反应器线程的职责：负责响应IO事件，并且分发到Handlers处理器。负责查询IO事件，当检测到一个IO事件，将其发送给相应的Handler处理器去处理。这里的IO事件，就是NIO中选择器监控的通道IO事件。
- Handlers处理器的职责：非阻塞的执行业务处理逻辑。与IO事件（或者选择键）绑定，负责IO事件的处理。完成真正的连接建立、通道的读取、处理业务逻辑、负责将结果写出到通道等。
OIO中用创建一个线程处理一个连接请求（Connection Per Thread），这样在一个业务没有处理完时不会阻塞其他请求的接收。但是频繁创建销毁切换线程有很大的代价，耗费大量的线程资源。
单线程版Reactor：
单线程处理事件监听并在同一个线程中处理业务数据。所以一旦某个handler业务阻塞，则其他所以的handler都无法得到执行。单线程模型也无法充分利用系统多核资源。
多线程的Reactor反应器：
升级Handler处理器，使用线程池。多线程，又要尽可能的高效率。
升级Reactor反应器，引入多个Selector选择器，提升选择大量通道的能力。
业务处理线程与负责服务监听和IO事件查询的反应器线程相隔离，避免服务器的连接监听受到阻塞。如果多核的CPU，可将反应器线程拆分为多个子反应器（SubReactor）线程。
反应器模式的优点和缺点：
优点
响应快，虽然同一反应器线程本身是同步的，但不会被单个连接的同步IO所阻塞；
编程相对简单，最大程度避免了复杂的多线程同步，也避免了多线程的各个进程之间切换的开销；
可扩展，可以方便地通过增加反应器线程的个数来充分利用CPU资源。
缺点
反应器模式增加了一定的复杂性，因而有一定的门槛，并且不易于调试。
反应器模式需要操作系统底层的IO多路复用的支持，如Linux中的epoll。如果操作系统的底层不支持IO多路复用，反应器模式不会有那么高效。
同一个Handler业务线程中，如果出现一个长时间的数据读写，会影响这个反应器中其他通道的IO处理。
充分利用系统资源，最大限度减少阻塞。
反应器模式与生产者消费者
反应器模式与观察着模式
代码整理
时间换空间，空间换时间
阅读笔记 《Netty、Redis、Zookeeper高并发实战》