linux 服务器开发人员必须要彻底理解的关于【Linux】IO 的线程模型

关于 IO 模型参考：【Linux】五种 IO 模型

reactor 模型应用视频讲解：epoll原理剖析以及reactor模型应用

c/c++linux 服务器开发高级架构师免费学习视频点击：C/C++Linux服务器开发高级架构师/Linux后台开发架构师

一、线程模型介绍

　　为了应对高并发的服务器端开发，微软在 2009 年提出了一种更优雅地实现异步编程的方式 Reactive Programming 即反应式编程。随后其他技术紧随其后，比如 ES6 通过引入类似的异步编程方式等。

　　在高性能的 I/O 设计中，有两个比较著名的模式 Reactor（反应堆模式）和 Proactor 模式（前摄器模式），其中 Reactor 模式用于同步 I/O，Proactor 用于异步 I/O 操作。

　　Reactor 模式称之为反应器模式，Reactor 模式使用 event loop 阻塞等在 io 上，一但 io 可以读或写，通过分发器，遍历事件注册队列，将事件分发到指定注册的处理器。由应用的处理器来再将流读取到缓冲区或写入操作系统，完成 io 操作。

　　Proctor 模式下读和写的方法是异步的，只需调用读和写即可。当有流可读取的时候，操作系统会将流传入 read 方法缓存区，并通知应用程序。对于写，当操作系统将 writer 写入完毕时，操作系统会主动通知应用程序。

　　proactor 模式的 Aio，流的读取和写入由操作系统完成，省去了遍历事件通知队列 selector 的代价。

　　Windows 上的 iocp 实现了 aio，linux 目前只有基于 epoll 模拟实现的 aio。

二、传统阻塞 I/O 服务模型

特点

• 采用阻塞式 I/O 模型获取输入数据

• 每个连接都需要独立的线程完成数据输入，业务处理，数据返回的完整操作

存在问题

• 当并发数较大时，需要创建大量线程来处理连接，系统资源占用较大

• 连接建立后，如果当前线程暂时没有数据可读，则线程就阻塞在 read 操作上，造成线程资源浪费

三、Reactor 模式

针对传统传统阻塞 I/O 服务模型的 2 个缺点，比较常见的有如下解决方案：

• 基于 I/O 复用模型，多个连接共用一个阻塞对象，应用程序只需要在一个阻塞对象上等待，无需阻塞等待所有连接。当某条连接有新的数据可以处理时，操作系统通知应用程序，线程从阻塞状态返回，开始进行业务处理

• 基于线程池复用线程资源，不必再为每个连接创建线程，将连接完成后的业务处理任务分配给线程进行处理，一个线程可以处理多个连接的业务

I/O 复用结合线程池，这就是 Reactor 模式基本设计思想

Reactor 模式，是指通过一个或多个输入同时传递给服务处理器的服务请求的事件驱动处理模式。 服务端程序处理传入多路请求，并将它们同步分派给请求对应的处理线程，Reactor 模式也叫 Dispatcher 模式，即 I/O 多了复用统一监听事件，收到事件后分发(Dispatch 给某进程)，是编写高性能网络服务器的必备技术之一

Reactor 模式中有 2 个关键组成：

• ReactorReactor 在一个单独的线程中运行，负责监听和分发事件，分发给适当的处理程序来对 IO 事件做出反应。 它就像公司的电话接线员，它接听来自客户的电话并将线路转移到适当的联系人

• Handlers 处理程序执行 I/O 事件要完成的实际事件，类似于客户想要与之交谈的公司中的实际官员。Reactor 通过调度适当的处理程序来响应 I/O 事件，处理程序执行非阻塞操作

根据 Reactor 的数量和处理资源池线程的数量不同，有 3 种典型的实现：

• 单 Reactor 单线程

• 单 Reactor 多线程

• 主从 Reactor 多线程

C/C++Linux 服务器开发高级架构师学习视频 点击 linux服务器学习资料 获取，内容知识点包括 Linux，Nginx，ZeroMQ，MySQL，Redis，线程池，MongoDB，ZK，Linux 内核，CDN，P2P，epoll，Docker，TCP/IP，协程，DPDK 等等。

下面详细介绍这 3 种实现

3.1 单 Reactor 单线程

其中，select 是前面 I/O 复用模型介绍的标准网络编程 API，可以实现应用程序通过一个阻塞对象监听多路连接请求，其他方案示意图类似

方案说明

• Reactor 对象通过 select 监控客户端请求事件，收到事件后通过 dispatch 进行分发

• 如果是建立连接请求事件，则由 Acceptor 通过 accept 处理连接请求，然后创建一个 Handler 对象处理连接完成后的后续业务处理

• 如果不是建立连接事件，则 Reactor 会分发调用连接对应的 Handler 来响应

• Handler 会完成 read->业务处理->send 的完整业务流程

优点模型简单，没有多线程、进程通信、竞争的问题，全部都在一个线程中完成

缺点

• 性能问题：只有一个线程，无法完全发挥多核 CPU 的性能 Handler 在处理某个连接上的业务时，整个进程无法处理其他连接事件，很容易导致性能瓶颈

• 可靠性问题：线程意外跑飞，或者进入死循环，会导致整个系统通信模块不可用，不能接收和处理外部消息，造成节点故障

使用场景客户端的数量有限，业务处理非常快速，比如 Redis，业务处理的时间复杂度 O(1)

3.2 单 Reactor 多线程

方案说明

• Reactor 对象通过 select 监控客户端请求事件，收到事件后通过 dispatch 进行分发

• 如果是建立连接请求事件，则由 Acceptor 通过 accept 处理连接请求，然后创建一个 Handler 对象处理连接完成后的续各种事件

• 如果不是建立连接事件，则 Reactor 会分发调用连接对应的 Handler 来响应

• Handler 只负责响应事件，不做具体业务处理，通过 read 读取数据后，会分发给后面的 Worker 线程池进行业务处理

• Worker 线程池会分配独立的线程完成真正的业务处理，如何将响应结果发给 Handler 进行处理

• Handler 收到响应结果后通过 send 将响应结果返回给 client

优点可以充分利用多核 CPU 的处理能力

缺点

• 多线程数据共享和访问比较复杂

• Reactor 承担所有事件的监听和响应，在单线程中运行，高并发场景下容易成为性能瓶颈

3.3 主从 Reactor 多线程

针对单 Reactor 多线程模型中，Reactor 在单线程中运行，高并发场景下容易成为性能瓶颈，可以让 Reactor 在多线程中运行

方案说明

• Reactor 主线程 MainReactor 对象通过 select 监控建立连接事件，收到事件后通过 Acceptor 接收，处理建立连接事件

• Accepto 处理建立连接事件后，MainReactor 将连接分配 Reactor 子线程给 SubReactor 进行处理

• SubReactor 将连接加入连接队列进行监听，并创建一个 Handler 用于处理各种连接事件

• 当有新的事件发生时，SubReactor 会调用连接对应的 Handler 进行响应

• Handler 通过 read 读取数据后，会分发给后面的 Worker 线程池进行业务处理

• Worker 线程池会分配独立的线程完成真正的业务处理，如何将响应结果发给 Handler 进行处理

• Handler 收到响应结果后通过 send 将响应结果返回给 client

优点

• 父线程与子线程的数据交互简单职责明确，父线程只需要接收新连接，子线程完成后续的业务处理

• 父线程与子线程的数据交互简单，Reactor 主线程只需要把新连接传给子线程，子线程无需返回数据

这种模型在许多项目中广泛使用，包括 Nginx 主从 Reactor 多进程模型，Memcached 主从多线程，Netty 主从多线程模型的支持

3.4 总结

3 种模式可以用个比喻来理解：餐厅常常雇佣接待员负责迎接顾客，当顾客入坐后，侍应生专门为这张桌子服务

• 单 Reactor 单线程接待员和侍应生是同一个人，全程为顾客服务

• 单 Reactor 多线程 1 个接待员，多个侍应生，接待员只负责接待

• 主从 Reactor 多线程多个接待员，多个侍应生

Reactor 模式具有如下的优点：

• 响应快，不必为单个同步时间所阻塞，虽然 Reactor 本身依然是同步的

• 编程相对简单，可以最大程度的避免复杂的多线程及同步问题，并且避免了多线程/进程的切换开销；

• 可扩展性，可以方便的通过增加 Reactor 实例个数来充分利用 CPU 资源

• 可复用性，Reactor 模型本身与具体事件处理逻辑无关，具有很高的复用性

3.3 Proactor 模型

在 Reactor 模式中，Reactor 等待某个事件或者可应用或个操作的状态发生（比如文件描述符可读写，或者是 socket 可读写），然后把这个事件传给事先注册的 Handler（事件处理函数或者回调函数），由后者来做实际的读写操作，其中的读写操作都需要应用程序同步操作，所以 Reactor 是非阻塞同步网络模型。如果把 I/O 操作改为异步，即交给操作系统来完成就能进一步提升性能，这就是异步网络模型 Proactor

Proactor 是和异步 I/O 相关的，详细方案如下：

• ProactorInitiator 创建 Proactor 和 Handler 对象，并将 Proactor 和 Handler 都通过 AsyOptProcessor（Asynchronous Operation Processor）注册到内核

• AsyOptProcessor 处理注册请求，并处理 I/O 操作

• AsyOptProcessor 完成 I/O 操作后通知 Proactor

• Proactor 根据不同的事件类型回调不同的 Handler 进行业务处理

• Handler 完成业务处理

可以看出 Proactor 和 Reactor 的区别：Reactor 是在事件发生时就通知事先注册的事件（读写在应用程序线程中处理完成）；Proactor 是在事件发生时基于异步 I/O 完成读写操作（由内核完成），待 I/O 操作完成后才回调应用程序的处理器来处理进行业务处理

理论上 Proactor 比 Reactor 效率更高，异步 I/O 更加充分发挥 DMA(Direct Memory Access，直接内存存取)的优势，但是有如下缺点：

• 编程复杂性由于异步操作流程的事件的初始化和事件完成在时间和空间上都是相互分离的，因此开发异步应用程序更加复杂。应用程序还可能因为反向的流控而变得更加难以 Debug

• 内存使用缓冲区在读或写操作的时间段内必须保持住，可能造成持续的不确定性，并且每个并发操作都要求有独立的缓存，相比 Reactor 模式，在 socket 已经准备好读或写前，是不要求开辟缓存的

• 操作系统支持 Windows 下通过 IOCP 实现了真正的异步 I/O，而在 Linux 系统下，Linux2.6 才引入，目前异步 I/O 还不完善

因此在 Linux 下实现高并发网络编程都是以 Reactor 模型为主