Reactor 和 Proactor 是两种经典的事件驱动 I/O 模型，广泛用于高并发网络服务器。它们的核心目标是高效处理大量并发连接，避免传统阻塞 I/O 的线程开销。
一、Reactor 模型
核心思想
“当事件就绪时，通知我，我来处理” —— 同步等待事件 + 主动处理
关键组件：
- Event:需要处理的事件
- Reactor：事件管理器，负责注册/注销事件、运行事件循环。
- Demultiplex：系统级 I/O 多路复用（如 epoll）。
- Event Handler：用户定义的回调函数。
工作流程：
- 事件注册：应用程序将感兴趣的 I/O 事件（如读、写、异常、关闭）注册到 Reactor。
-
事件循环： Reactor 使用 I/O多路复用器（如
select、poll、epoll）同步阻塞等待事件就绪。 - 事件分发：一旦有事件就绪（如 socket 可读），Reactor 回调对应的 Handler（处理函数）。
-
Handler 执行： 应用程序在 当前线程中同步执行 I/O 操作（如
read()）。
典型实现：
- 单线程 Reactor：一个线程负责所有事件的监听、分发和处理（包括 I/O 操作和业务逻辑）
- 多线程 Reactor：一个 Reactor 线程负责事件监听和 I/O 操作，多个工作线程（Worker Thread）负责处理业务逻辑，实现 I/O 与业务的分离。
- 主从 Reactor：多个 Reactor 线程分工协作，主 Reactor（Main Reactor）负责处理连接事件，从 Reactor（Sub Reactor）负责处理已连接 socket 的读写事件，结合工作线程池处理业务。
二、Proactor 模型
核心思想：
“你帮我异步完成 I/O，完成后通知我” —— 异步 I/O + 事件通知
工作流程：
-
发起异步操作：应用程序调用异步 API（如 Windows 的
ReadFile+ IOCP），立即返回。 - 系统执行 I/O： 操作系统在后台线程/硬件中完成 I/O。
- 完成通知：I/O 完成后，系统通过 完成端口（IOCP）将结果投递到队列。
- Proactor 分发： Proactor 从完成队列取出事件，调用对应的 ***pletion Handler。
关键组件：
- Proactor：管理异步操作和完成事件。
- Asynchronous Operation Processor：操作系统提供的异步 I/O 机制（如 IOCP）。
- ***pletion Handler：I/O 完成后的回调。
典型实现：
- Windows IOCP（Inter*** ***pletion Port）
- Boost.Asio 的 Proactor 模式（可选）
三、Reactor vs Proactor 对比
| 特性 | Reactor | Proactor |
|---|---|---|
| I/O 模型 | 同步非阻塞（事件就绪后同步读写） | 异步 I/O（系统完成后再通知） |
| 事件触发时机 | 就绪事件（可读/可写） | 完成事件（读完/写完） |
| 操作系统依赖 | Linux select/poll/epoll | Windows IOCP，Linux AIO |
| 编程复杂度 | 较低 | 较高 |
| 性能（小数据） | 优秀 | 稍逊（异步开销） |
| 性能（大数据） | 一般（同步读写可能阻塞） | 优秀（真正异步） |
| 典型应用 | Nginx、***ty、Redis、Node.js | Windows 高性能服务器、Boost.Asio |
四、知名框架实现
- Nginx：主从 Reactor（多进程 + epoll）
- Muduo：主从 Reactor（多线程 + epoll）
- ***ty：多线程 Reactor（默认）
- Boost.Asio：支持 Reactor 和 Proactor（可切换）
五、总结
| 模型 | 口诀 |
|---|---|
| Reactor | “我等你准备好，我来读写” |
| Proactor | “你去读写，好了告诉我” |
Linux 生态推荐 Reactor，Windows 高性能可选 Proactor。
