前言
首先让我们来回顾一下select、poll和epoll是如何获取网络事件的：
在获取事件时，先把我们要关心的连接传给内核，再由内核检测：
- 若没有事件发生，线程只需阻塞在这个系统调用，而无需使用类似于线程池轮询调用read操作来判断是否有数据；
- 如果有事件发生，内核会返回产生了事件的连接，线程就会从阻塞状态返回，然后在内核态中再处理这些连接处理这些对应的业务即可。
我们也发觉，当下网络高性能的一个主要原因就是：IO多路复用的使用，但是使用过IO多路复用接口编写网络程序的人都会觉得这种开发的效率属实不高，并且还需要关注很多的细节。
于是，基于面向对象的思想，巨佬们就对IO复用接口进行了封装，让使用者不用考虑底层API的细节，只需要关注应用代码的编写。
下面我们步入正题：
- Reactor 和 Proactor 都是高性能网络模式
我们一一来介绍
Reactor模式
-
无论是C++还是Java编写的网络框架，大多数都是基于Reactor模型进行设计和开发，Reactor模式是基于事件驱动，特别适合处理海量的IO事件。Reactor模式，市面上常见的开源软件很多都采用了这个方案，比如 Redis、Nginx、Netty等等，所以学好这个模式设计的思想，有助于我们理解很多开源软件。
-
Reaactor的英译即【反应堆】—— 这里主要是指对事件作出响应。
-
事实上，Reactor 模式也叫 Dispatcher 模式，我觉得这个名字更贴合该模式的含义，即IO多路复用监听事件，收到事件后，根据事件类型分配（Dispatch）给某个进程 / 线程。
三种角色
- Reactor：负责
监听和分配事件，将IO事件分派给对应的Handler。【新的事件包含连接建立就绪、读就绪、写就绪等】 - Acceptor：处理客户端的连接，并分配请求到处理器链中。
- Handler：将自身与事件绑定，执行非阻塞读、写任务，完成channel的读入，完成处理业务逻辑后，负责将结果写出channel，可用资源池来管理。
一般来说，C 语言实现的是「单 Reactor 单进程」的方案，因为 C 语编写完的程序，运行后就是一个独立的进程，不需要在进程中再创建线程。
而 Java 语言实现的是「单 Reactor 单线程」的方案，因为 Java 程序是跑在 Java 虚拟机这个进程上面的，虚拟机中有很多线程，我们写的 Java 程序只是其中的一个线程而已。
单Reactor单线程模型
Reactor线程负责多路分离套接字，accept新链接，并分派请求到Handler。
消息处理流程：
- Reactor 对象通过 select （IO 多路复用接口） 监听事件，收到事件后通过 dispatch 进行分发，具体分发给 Acceptor 对象还是 Handler 对象，还要看收到的事件类型；
- 如果是连接建立的事件，则由acceptor接受连接，Acceptor 对象会通过 accept 方法 获取连接，并创建Handler来处理后续事件。
- 如果不是建立连接事件，则Reactor会分发调用Handler来响应。
- Handler会完成read——>业务处理——>send的完整业务流程。（这里注意和后面多线程的区别）
单Reactor单线程模型只是在代码上进行了组件的区分，但是整体操作还是单线程，不能充分利用硬件资源，Handler业务处理部分时，整个进程是无法处理其他连接的事件的，如果业务处理耗时比较长，那么就造成响应的延迟；
- 所以，单 Reactor 单进程的方案不适用计算机密集型的场景，只适用于业务处理非常快速的场景（小容量应用场景）， 不适合高负载，大并发的应用场景
原因如下：
- 即使Reactor线程的CPU负荷达到100%，也无法满足海量数据的编码，解码，读取和发送。
- 当Reactor线程负载过重后，处理速度会变慢，这会导致大量客户端连接超时，超时之后往往会进行重发，更加加重Reactor的负载，最终会导致大量消息积压和处理超时，成为系统性能瓶颈。
- 一旦Reactor线程意外中断或者进入死循环，会导致整个系统的通信模块不可用，不能接受和处理外部消息，造成结点故障。
Redis 是由 C 语言实现的，它采用的正是「单 Reactor 单进程」的方案，因为 Redis 业务处理主要是在内存中完成，操作的速度是很快的，性能瓶颈不在 CPU 上，所以 Redis 对于命令的处理是单进程的方案
为了解决这些问题：演化出单Reactor的多线程模型
单Reactor的多线程模型
该模型在事件处理器（Handler）部分采用了多线程（线程池）
消息处理流程：
- Reactor对象通过select监控客户端请求事件，收到事件后通过dispatch进行分发。
- 如果是连接建立的事件，则由acceptor接受连接，Acceptor 对象会通过 accept 方法 获取连接，并创建Handler来处理后续事件。
- 如果不是建立连接事件，则Reactor会分发调用Handler来响应。
下面就和单线程有所不同了：
- Handler只负责响应事件，不做业务处理，通过read读取事件后，会分发给后面的线程池中的Processor来进行业务处理。
- 子线程里的 Processor 对象就进行业务处理，处理完后，将结果发给主线程中的 Handler 对象，接着由 Handler 通过 send 方法将响应结果发送给 client。
比较
相对于第一种单Reactor的单线程模型，在处理业务逻辑时（也就是获取到IO的读写事件之后），交由线程池来处理，Handler收到响应之后通过send将响应结果返回给客户端，这样可以降低Reactor的性能开销，从而更专注的做事件分发工作——>提高整个应用的吞吐。
但是，这个模型仍然存在以下的问题：
- 多线程数据共享和访问比较复杂，如果子线程完成业务处理后，把结果传递给主线程Reactor进行发送，就会涉及共享数据的互斥和保护机制。
- Reactor承担所有事件的监听和响应，只在主线程中运行，可能会存在性能问题，例如并发百万客户端连接，或者服务端需要对客户端握手进行安全认证，但是认证本身非常损耗性能。
为了解决性能问题，产生了第三种主从Reactor多线程模型
主从Reactor多线程模型
比起第二种模型，它将Reactor分成两部分：
其中：
- 主线程中的
MainReactor 对象通过 select 监控连接建立事件，收到事件后通过 Acceptor 对象中的 accept获取连接，将新的连接分配给某个子线程； - 子线程中的
SubReactor 对象将 MainReactor 对象分配的连接加入 select 继续进行监听，并创建一个 Handler 用于处理连接的响应事件。 - 如果有新的事件发生时，
SubReactor 对象会调用当前连接对应的 Handler 对象来进行响应。 - Handler 对象通过 read -> 业务处理 -> send 的流程来完成完整的业务流程。
多 Reactor 多线程的方案虽然看起来复杂的，但是实际实现时比单 Reactor 多线程的方案要简单的多，原因如下：
- 主线程和子线程分工明确，主线程只负责接收新连接，子线程负责完成后续的业务处理。
- 主线程和子线程的交互很简单，主线程只需要把新连接传给子线程，子线程无须返回数据，直接就可以在子线程将处理结果发送给客户端。
大名鼎鼎的两个开源软件 Netty 和 Memcache 都采用了「多 Reactor 多线程」的方案。
总结
Reactor模型具有以下的优点：
- 响应快，不必为单个同步时间所阻塞，因为Reactor本来就是同步的；
- 编程相对简单，可以最大程度的避免复杂的多线程及同步问题，并且避免了多线程/多进程的切换开销；
- 可扩展性，可以方便地通过Reactor实例个数来充分利用CPU资源；
- 可复用性：Reactor模型本身与具体时间处理逻辑无关，具有很高的复用性。
- 第一种方案单 Reactor 单进程 /线程，不用考虑进程间通信以及数据同步的问题，因此实现起来比较简单，这种方案的缺陷在于无法充分利用多核
CPU，而且处理业务逻辑的时间不能太长，否则会延迟响应，所以不适用于计算机密集型的场景，适用于业务处理快速的场景，比如 Redis采用的是单 Reactor 单进程的方案。 - 第二种方案单 Reactor 多线程，通过多线程的方式解决了方案一的缺陷，但它离高并发还差一点距离，差在只有一个 Reactor对象来承担所有事件的监听和响应，而且只在主线程中运行，在面对瞬间高并发的场景时，容易成为性能的瓶颈的地方。
- 第三种方案多 Reactor 多进程 / 线程，通过多个 Reactor 来解决了方案二的缺陷，主 Reactor只负责监听事件，响应事件的工作交给了从 Reactor，Netty 和 Memcache 都采用了「多 Reactor多线程」的方案，Nginx 则采用了类似于 「多 Reactor 多进程」的方案。
Reactor 可以理解为「来了事件操作系统通知应用进程，让应用进程来处理」，而 Proactor 可以理解为「来了事件操作系统来处理，处理完再通知应用进程」。
因此，真正的大杀器还是 Proactor，它是采用异步 I/O 实现的异步网络模型，感知的是已完成的读写事件，而不需要像 Reactor 感知到事件后，还需要调用 read 来从内核中获取数据。
不过，无论是 Reactor，还是 Proactor，都是一种基于「事件分发」的网络编程模式，区别在于 Reactor 模式是基于「待完成」的 I/O 事件，而 Proactor 模式则是基于「已完成」的 I/O 事件。
下一篇，我们来了解Proactor模型
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
