设计模式-Reactor模型（反应器设计模式）
是一种基于事件驱动的设计模式，在事件驱动的应用中，将一个或多个客户的服务请求分离（demultiplex）和调度（dispatch）给应用程序。在事件驱动的应用中，同步地、有序地处理同时接收的多个服务请求 一般出现在高并发系统中，比如Netty，Redis等
优点
1）响应快，不会因为单个同步而阻塞，虽然Reactor本身依然是同步的
2）编程相对简单，最大程度的避免复杂的多线程及同步问题，并且避免了多线程/进程的切换开销
3）可扩展性，可以方便的通过增加Reactor实例个数来充分利用CPU资源
缺点
1）相比传统的简单模型，Reactor增加了一定的复杂性，因而有一定的门槛，并且不易于调试
2）Reactor模式需要系统底层的支持，比如java中的Selector支持，操作系统的select系统调用支持
通俗理解：KTV例子 前台接待，服务人员带领去开机器
Reactor模式基于事件驱动，适合处理海量的IO事件，属于同步非阻塞IO（NIO）
Reactor单线程模型（比较少用）
如果用户量很多是处理不过来的
1）作为NIO服务端，接收客户端的TCP连接；作为NIO客户端，向服务端发起TCP连接
2）服务端读请求数据并响应；客户端写请求并读取响应
使用场景： 对应小业务则适合，编码简单；对于高负载、大并发的应用场景不适合，一个NIO线程处理太多请求，则负载过高，并且可能响应变慢，导致大量请求超时，而且万一线程挂了，则不可用了
Reactor多线程模型
一个Acceptor线程，一组NIO线程。一般是使用自带的线程池，包含一个任务队列和多个可用线程
使用场景： 满足大多数产加工
但是当Acceprot需要做复杂操作的时候，比如你到KTV唱歌，前台需要拿你的身份证验证一下你是否是通缉人员，这种认证操作，在高并发情况下则也会出现性能问题。很多的请求进来无法到后面的线程处理，大量请求堆积
Reactor主从线程模型
Acceptor不在是一个线程，而是一组NIO线程；IO线程也是一组NIO线程，这样就是两个线程池去处理接入连接和处理IO 。可解决上面多线程模型
使用场景：满足大部分场景，也是Netty推荐模型
附属资料：
为什么Netty使用NIO而不是AIO，是同步非阻塞还是异步非阻塞？
答案：
在Linux系统上，AIO的底层实现仍使用EPOLL，与NIO相同，因此在性能上没有明显的优势
Netty整体架构是reactor模型，采用epoll机制，所以往深的说，还是IO多路复用模式，所以也可说netty是同步非阻塞模型（看的层次不一样）
很多人说这是netty是基于Java NIO 类库实现的异步通讯框架
特点：异步非阻塞、基于事件驱动，性能高，高可靠性和高可定制性。
参考资料：
https://github.com/netty/netty/issues/2515