如何深刻理解Reactor和Proactor

---

前言：
网络框架的设计离不开 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 事件准备就绪了，则