前言 ：
网络框架的设计离不开 I/O 线程模型，线程模型的优劣直接决定了系统的吞吐量、可扩展性、安全性等。目前主流的网络框架，在网络 IO 处理层面几乎都采用了I/O 多路复用方案(又以epoll为主)，这是服务端应对高并发的性能利器。
进一步看，当上升到整个网络模块时，另一个常常听说的模式出现了 ---- 「Reactor 模式」，也叫反应器模式，本质是一个事件转发器，是网络模块核心中枢，负责将读写事件分发给对应的读写事件处理者,将连接事件交给连接处理者以及业务事件交给业务线程。
1. 前置知识
1.1 io
可以看到，网络请求先后经历 服务器网卡、内核、连接建立、数据读取、业务处理、数据写回等一系列过程。
其中，连接建立(accept)、数据读取(read)、数据写回(write)等操作都需要操作系统内核提供的系统调用，最终由内核与网卡进行数据交互，这些 IO 调用消耗一般是比较高的，比如 IO 等待、数据传输等。
最初的处理方式是，每个连接都用独立的一个线程来处理这一系列的操作，即 建立连接、数据读写、业务逻辑处理；这样一来最大的弊端在于，N 个连接就需要 N 个线程资源，消耗巨大。
所以，在网络模型演化过程中，不断的对这几个阶段进行拆分，比如，将建立连接、数据读写、业务逻辑处理等关键阶段分开处理。这样一来，每个阶段都可以考虑使用单线程或者线程池来处理，极大的节约线程资源，又能获得超高性能。
1.1.1 阻塞IO
阻塞IO：通常是用户态线程通过系统调用阻塞读取网卡传递的数据，我们知道，在 TCP 三次握手建立连接之后，真正等待数据的到来需要一定时间；
这个时候，在该模式下用户线程会一直阻塞等待网卡数据准备就绪，直到完成数据读写完成；可以看到，用户线程大部分都在等待 IO 事件就绪，造成资源的急剧浪费
1.1.2 非阻塞IO
与阻塞 IO 相反，如果数据未就绪会直接返回，应用层轮询读取/查询，直到成功读取数据。
这里最后一次 read 调用，获取数据的过程，是一个同步的过程，是需要等待的过程。这里的同步指的是内核态的数据拷贝到用户程序的缓存区这个过程。
epoll: 是非阻塞IO的一种特例，也是目前最经典、最常用的高性能IO模型。其具体处理方式是：先查询 IO 事件是否准备就绪，当 IO 事件准备就绪了，则会真正的通过系统调用实现数据读写；
无论 read 和 send 是阻塞 I/O，还是非阻塞 I/O 都是同步调用。因为在 read 调用时，内核将数据从内核空间拷贝到用户空间的过程都是需要等待的，也就是说这个过程是同步的，如果内核实现的拷贝效率不高，read 调用就会在这个同步过程中等待比较长的时间
1.1.3 异步IO
- 阻塞 I/O 好比，你去饭堂吃饭，但是饭堂的菜还没做好，然后你就一直在那里等啊等，等了好长一段时间终于等到饭堂阿姨把菜端了出来（数据准备的过程），但是你还得继续等阿姨把菜（内核空间）打到你的饭盒里（用户空间），经历完这两个过程，你才可以离开。
- 非阻塞 I/O 好比，你去了饭堂，问阿姨菜做好了没有，阿姨告诉你没，你就离开了，过几十分钟，你又来饭堂问阿姨，阿姨说做好了，于是阿姨帮你把菜打到你的饭盒里，这个过程你是得等待的。
- 异步 I/O 好比，你让饭堂阿姨将菜做好并把菜打到饭盒里后，把饭盒送到你面前，整个过程你都不需要任何等待。
1.2 事件驱动
前面我们提到：将一个正常的请求分成多段来看待，每一段都可以分别进行优化（看场景需要）
经典的一种切分方法是将「连接」和「业务线程」分开处理，当「连接层」有事件触发时提交给「业务线程」，避免了业务线程因「网络数据处于准备中」导致的长时间等待问题，节省线程资源，这就是大名鼎鼎的事件驱动模型。
事件驱动的核心是，以事件为连接点，当有IO事件准备就绪时，以事件的形式通知相关线程进行数据读写，进而业务线程可以直接处理这些数据，这一过程的后续操作方，都是被动接收通知，看起来有点像回调操作；
这种模式下，IO 读写线程、业务线程工作时，必有数据可操作执行，不会在 IO 等待上浪费资源，这便是事件驱动的核心思想。
2 Reactor 模型(同步非阻塞io)
Reactor 翻译过来的意思是「反应堆」，可能大家会联想到物理学里的核反应堆，实际上并不是的这个意思。这里的反应指的是「对事件反应」，也就是来了一个事件，Reactor 就有相对应的反应/响应。
事实上，Reactor 模式也叫 Dispatcher 模式，我觉得这个名字更贴合该模式的含义，即 I/O 多路复用监听事件，收到事件后，根据事件类型分配（Dispatch）给某个进程 / 线程 。
Reactor 模式主要由 Reactor 和处理资源池这两个核心部分组成，它俩负责的事情如下：
- Reactor 负责监听和分发事件（主进程或者线程）
- 事件类型包含连接事件、读写事件；处理资源池负责处理事件，如 read -> 业务逻辑 -> send；（工作者进程或线程）
Reactor 模式是灵活多变的，可以应对不同的业务场景，灵活在于：
- Reactor 的数量可以只有一个，也可以有多个；
- 处理资源池可以是单个进程 / 线程，也可以是多个进程 /线程；
根据以上情况就有以下分类 :(多Reactor 单进程 / 线程)无明显优势；
reactor模型主要分类
- 单 Reactor 单进程 / 线程；经典代表Redis
- 单 Reactor 多线程 / 进程； c++经典代表Muduo
- 多 Reactor 多进程 / 线程(也是主从)；c++经典代表 多进程Nginx
2.1 单 Reactor 单进程 / 线程
可以看到进程(应用程序)里有 Reactor、Acceptor、Handler 这三个对象：
- Reactor 对象的作用是监听和分发事件；(主)
- Acceptor 对象的作用是获取连接；
- Handler 对象的作用是处理业务；
接下来，介绍下「单 Reactor 单进程」这个方案：
- Reactor 对象通过 select(IO 多路复用接口） 监听事件，收到事件后通过 dispatch 进行分发，
- 具体分发给 Acceptor 对象还是 Handler 对象，还要看收到的事件类型；如果是连接建立的事件，则交由 Acceptor 对象进行处理，Acceptor 对象会通过 accept 方法 获取连接，并创建一个 Handler 对象来处理后续的响应事件；
- 如果不是连接建立事件， 则交由当前连接对应的 Handler 对象来进行响应；Handler 对象通过 read -> 业务处理 -> send 的流程来完成完整的。(回调事件)
优点
单 Reactor 单进程的方案因为全部工作都在同一个进程内完成，所以实现起来比较简单，不需要考虑进程间通信，也不用担心多进程竞争。
缺点
- 第一个缺点，因为只有一个进程，无法充分利用 多核 CPU 的性能；
- 第二个缺点，Handler 对象在业务处理时，整个进程是无法处理其他连接的事件的，如果业务处理耗时比较长，那么就造成响应的延迟；
单 Reactor 单进程的方案不适用计算机密集型的场景，只适用于业务处理非常快速的场景（这解释为什么redis有百万并发的瓶颈）
2.2 单 Reactor 多线程 / 多进程
- Reactor 对象通过 epoll（IO 多路复用接口） 监听事件，收到事件后通过 dispatch 进行分发，具体分发给 Acceptor 对象还是 Handler 对象，还要看收到的事件类型；
- 如果是连接建立的事件，则交由 Acceptor 对象进行处理，Acceptor 对象会通过 accept 方法 获取连接，并创建一个 Handler 对象来处理后续的响应事件；
- 如果不是连接建立事件， 则交由当前连接对应的 Handler 对象来进行响应；
上面的三个步骤和单 Reactor 单线程方案是一样的，接下来的步骤就开始不一样了：
- Handler 对象不再负责业务处理，只负责数据的接收和发送，Handler 对象通过 read 读取到数据后，会将数据发给子线程里的 Processor 对象进行业务处理；
- 子线程里的 Processor 对象就进行业务处理，处理完后，将结果发给主线程中的 Handler 对象，接着由 Handler 通过 send 方法将响应结果发送给 client**；
优点
- 能够充分利用多核 CPU 的性能
缺点 - 那既然引入多线程，那么自然就带来了多线程竞争资源的问题。
- 因为一个 Reactor 对象承担所有事件的监听和响应，而且只在主线程中运行，在面对瞬间高并发的场景时，容易成为性能的瓶颈的地方
2.3 多 Reactor 多进程 / 线程
- 主线程中的 MainReactor 对象通过 epoll监控连接建立事件，收到事件后通过 Acceptor 对象中的 accept 获取连接，将新的连接分配给某个子线程；
- 子线程中的 SubReactor 对象将 MainReactor 对象分配的连接加入 select 继续进行监听，并创建一个 Handler 用于处理连接的响应事件。
- 如果有新的事件发生时，SubReactor 对象会调用当前连接对应的 Handler 对象来进行响应。
- Handler 对象通过 read -> 业务处理 -> send 的流程来完成完整的业务流程。
多 Reactor 多线程的方案虽然看起来复杂的，但是实际实现时比单 Reactor 多线程的方案要简单的多，原因如下：
- 主线程和子线程分工明确，主线程只负责接收新连接，
- 子线程负责完成后续的业务处理。主线程和子线程的交互很简单，主线程只需要把新连接传给子线程，子线程无须返回数据，直接就可以在子线程将处理结果发送给客户端。
nginx(多进程)
不是采用标准的，具体差异表现在主进程中仅仅用来初始化 socket，并没有创建 mainReactor 来 accept 连接，而是由子进程的 Reactor 来 accept 连接，通过锁来控制一次只有一个子进程进行 accept（防止出现惊群现象），子进程 accept 新连接后就放到自己的 Reactor 进行处理，不会再分配给其他子进程
Proactor(异步非阻塞io)
Proactor 是异步网络模式， 感知的是已完成的读写事件。在发起异步读写请求时，需要传入数据缓冲区的地址（用来存放结果数据）等信息，这样系统内核才可以自动帮我们把数据的读写工作完成，这里的读写工作全程由操作系统来做，并不需要像 Reactor 那样还需要应用进程主动发起 read/write 来读写数据，操作系统完成读写工作后，就会通知应用进程直接处理数据.
因此，**Reactor 可以理解为「来了事件操作系统通知应用进程，让应用进程来处理」，而 Proactor 可以理解为「来了事件操作系统来处理，处理完再通知应用进程」。**这里的「事件」就是有新连接、有数据可读、有数据可写的这些 I/O 事件这里的「处理」包含从驱动读取到内核以及从内核读取到用户空间。
举个实际生活中的例子，Reactor 模式就是快递员在楼下，给你打电话告诉你快递到你家小区了，你需要自己下楼来拿快递。而在 Proactor 模式下，快递员直接将快递送到你家门口，然后通知你。
无论是 Reactor，还是 Proactor，都是一种基于「事件分发」的网络编程模式，区别在于 Reactor 模式是基于「待完成」的 I/O 事件 ，而 Proactor 模式则是基于「已完成」的 I/O 事件。
接下来，一起看看 Proactor 模式的示意图:
介绍一下 Proactor 模式的工作流程：
- Proactor Initiator 负责创建 Proactor 和 Handler 对象，并将 Proactor 和 Handler 都通过 Asynchronous Operation Processor 注册到内核；
- Asynchronous Operation Processor 负责处理注册请求，并处理 I/O 操作；Asynchronous Operation Processor 完成 I/O 操作后通知 Proactor；
- Proactor 根据不同的事件类型回调不同的 Handler 进行业务处理；Handler 完成业务处理；
可惜的是，在 Linux 下的异步 I/O 是不完善的， aio 系列函数是由 POSIX 定义的异步操作接口，不是真正的操作系统级别支持的，而是在用户空间模拟出来的异步，并且仅仅支持基于本地文件的 aio 异步操作，网络编程中的 socket 是不支持的，这也使得基于 Linux 的高性能网络程序都是使用 Reactor 方案。
而 Windows 里实现了一套完整的支持 socket 的异步编程接口，这套接口就是 IOCP，是由操作系统级别实现的异步 I/O，真正意义上异步 I/O，因此在 Windows 里实现高性能网络程序可以使用效率更高的 Proactor 方案。