Reactor 模型

这是一个在高性能网络编程中至关重要的设计模式，它用于高效地处理大量的并发连接，而无需为每个连接创建昂贵的线程。像 Node.js、Nginx、Netty、Redis 等众多知名软件的核心都基于 Reactor 模型。

1. 核心思想：不要等，有事我喊你

Reactor 模式的核心思想是 “非阻塞同步” 和 “事件驱动”。

• 传统多线程模型：为每个客户端连接创建一个线程。线程在等待数据（例如调用 read）时会被阻塞（休眠），直到数据到达。当连接数非常多时（C10K 问题），线程上下文切换的开销会变得巨大，耗尽系统资源。

• Reactor 模型：由一个或多个线程（Reactor）来循环监听各种事件（如连接建立、数据到达、数据可写）。当某个事件发生时，Reactor 就会分发（Dispatch） 这个事件给对应的处理程序（Handler）进行快速处理。处理程序自身是非阻塞的，它会立即返回，不会等待操作完成。

用一个生动的比喻来理解：

• 传统模型：就像一家餐厅，每个顾客（连接）都有一个专属服务员（线程）。服务员点完餐后，就站在厨房门口等菜做好，这期间他不能服务其他顾客。

• Reactor 模型：只有一个或少数几个服务员（Reactor 线程）。他们不停地在餐厅里巡逻（事件循环），接收新顾客（连接事件）、记录点餐（读事件）。他们把点菜单交给厨房（工作线程池），然后就去忙别的了。厨房做好菜后，会把菜放在出餐口（事件就绪），服务员巡逻到出餐口时（写事件就绪），就会把菜端给顾客。

2. Reactor 模型的核心组成部分

1. Reactor（反应器）：

   • 整个模式的大脑。运行在一个独立的线程中。

   • 其核心是一个事件循环（Event Loop），它会监听和分发事件。

   • 它使用一个 I/O 多路复用器（如 select, poll, epoll, kqueue） 来同时监听多个文件描述符（Socket）上的事件。

2. Handlers（事件处理器）：

   • 每个 Handler 负责处理一种特定类型的事件（如连接事件、读事件、写事件）。

   • 它们实现了具体的业务逻辑。当 Reactor 将事件分发给它们时，它们会执行相应的操作（如读取数据、处理数据、发送响应）。

3. Demultiplexer（事件分离器 / I/O 多路复用器）：

   • 这是操作系统提供的机制（如 Linux 的 epoll），是 Reactor 能够高效工作的基石。

   • 它允许一个线程同时监视多个网络连接，并在任何一个连接有数据可读或可写时通知 Reactor。

3. Reactor 的工作流程

一个典型的 Reactor 处理 TCP 请求的流程如下：

1. 注册监听：Reactor 通过 Demultiplexer 注册对 Acceptor（接受连接的处理器）的“可读”事件感兴趣，即监听是否有新的连接到来。

2. 事件循环（Event Loop）：Reactor 启动循环，调用 Demultiplexer 的 select 方法。该方法会阻塞，直到一个或多个被监视的事件发生。

3. 事件通知：当有新连接到来时，Demultiplexer 返回，通知 Reactor “Acceptor 对应的 Socket 可读了”。

4. 事件分发：Reactor 根据事件类型，将事件分发给预先注册好的 Acceptor Handler。

5. 处理事件：

   • Acceptor：接受新连接，创建一个新的 Socket Channel。并为这个新 Channel 创建一个对应的 Handler（如 Read Handler），并将其“可读”事件注册到 Demultiplexer 中，由 Reactor 继续监听。

   • Read Handler：当某个客户端发送数据，导致 Socket 可读时，Reactor 会分发该事件给对应的 Read Handler。Handler 会非阻塞地读取数据，并进行业务处理。

   • Write Handler：业务处理完成后，可能需要返回数据。Handler 会将响应数据写入输出缓冲区，并注册“可写”事件。当网络可写时，Reactor 会分发“可写”事件给 Write Handler，由它负责将数据发送出去。

6. 回到步骤 2，继续事件循环。

4. Reactor 的三种常见变体

根据 Reactor 线程和业务处理线程的数量和分工，可以分为三类：

1. 单 Reactor 单线程

   • 所有工作（事件监听、连接建立、数据读写、业务处理）都在一个线程内完成。

   • 优点：模型简单，没有线程切换和同步的开销。

   • 缺点：无法充分利用多核CPU；一个Handler处理慢会阻塞整个系统。

   • 适用场景：业务处理非常快速的场景，如 Redis。

2. 单 Reactor 多线程

   • Reactor 线程只负责事件监听和分发（包括接受新连接和I/O读写）。

   • 当有数据可读时，Reactor 读取数据后，将其封装成一个任务对象，交给线程池去进行业务处理。

   • 处理完成后，线程池将结果返回给 Reactor 线程，由 Reactor 将响应结果发送给客户端。

   • 优点：充分利用多核CPU，业务处理不会阻塞主循环。

   • 缺点：Reactor 仍然是单点，处理所有客户端的I/O操作，高并发时可能成为瓶颈；多线程间数据同步复杂。

3. 主从 Reactor 多线程

   • 主 Reactor：只负责监听和接受新连接。一旦接受，将新连接的 Socket Channel 分配给子 Reactor。

   • 子 Reactor：有多个，每个都在自己的线程中运行。主 Reactor 将新连接注册到某个子 Reactor 上，由该子 Reactor 负责这个连接后续的所有 I/O 事件（读、写）的监听和分发。业务处理依然交给线程池。

   • 优点：职责明确，性能更高。主 Reactor 专注接受连接，子 Reactor 分担了I/O压力，进一步提升了系统吞吐量。这是 Netty、Nginx 等框架采用的模式。

5. Reactor vs. Proactor

• Reactor：基于 同步I/O。它监听的是“I/O操作是否就绪”（例如“socket是否有数据可读了”）。就绪后，需要应用程序自己执行实际的I/O操作（调用 read 去读取数据）。

• Proactor：基于 异步I/O。它监听的是“I/O操作是否完成”（例如“数据已经读完了”）。操作系统会帮你完成实际的I/O操作，完成后再通知你，你直接处理结果即可。

简单说：

• Reactor：epoll_wait -> 通知可读 -> 应用程序调用 read

• Proactor：aio_read -> 操作系统读 -> 通知已读完 -> 应用程序处理数据