3、Proactor模式与异步IO：Windows IOCP原理、Linux AIO与io_uring、Proactor vs Reactor选型
聊到网络线程模型，Reactor 大家都很熟了。但真正让服务端吞吐量再上一个台阶的，其实是 Proactor 模式。说白了，Reactor 是「我通知你，你来读」；Proactor 是「我帮你读完，再通知你」。这个区别，决定了两种模式在 IO 密集型场景下的命运。
我个人习惯把 Proactor 叫做「真·异步」。因为它把数据搬运的脏活累活，全交给操作系统了。你想想看，你的业务线程只需要处理已经躺在内存里的数据，多清爽。
Windows IOCP：Proactor 的教科书实现
IOCP（I/O Completion Port）是 Windows 上最成熟的异步 IO 模型。我在做 Windows 游戏服务器时，被它救过好几次命。
它的核心机制就四个字：完成回调。你发起一个 ReadFile 或 WSARecv，不等待结果，直接返回。等操作系统把数据从网卡拷贝到用户缓冲区后，它会把一个「完成包」扔到 IOCP 的队列里。你的工作线程只需要从这个队列里取包，然后处理。
IOCP 关键数据结构
- 完成端口（Completion Port）：全局队列，所有 socket 的完成事件都往这里投递。
- 重叠结构（OVERLAPPED）：每个 IO 请求携带的上下文，包含缓冲区指针、数据长度、用户自定义数据。
- 工作线程池：调用 GetQueuedCompletionStatus 阻塞等待，拿到完成包后处理业务逻辑。
这里有个坑。我曾经在项目里发现，如果工作线程数设置不当，IOCP 的并发度反而会下降。Windows 的 IOCP 内部有一个「并发量」参数，默认是 CPU 核心数。如果你开了 100 个线程，但并发量没调，实际上只有 N 个线程在同时处理完成包，其他线程都在排队。
避坑指南：我曾经在 16 核机器上开了 64 个工作线程，结果吞吐量还不如 16 个线程。后来把并发量调到 64，性能直接翻倍。记住：IOCP 的线程数 ≠ 并发处理数。
Linux AIO：理想丰满，现实骨感
Linux 的异步 IO 之路走得比较曲折。早期的 POSIX AIO（aio_read / aio_write）其实是在用户态用线程池模拟的，根本不是真正的内核异步。真正的内核原生 AIO 是 libaio，但它有两个硬伤：
- 只支持 O_DIRECT 模式：必须绕过页缓存，直接读写磁盘。这意味着你没法用它做网络 IO。
- 系统调用开销大：每次提交 IO 请求都要调用 io_submit，完成事件要调用 io_getevents，上下文切换成本不低。
我记得有一次在 Linux 上做高性能日志系统，想用 AIO 来异步写文件。结果发现，小文件的随机写场景下，AIO 的性能还不如用 mmap + 同步写。原因就是 O_DIRECT 要求 512 字节对齐，而且每次写都要刷盘，太慢了。
我的建议：除非你是在做数据库或存储引擎，否则别碰 Linux AIO。网络 IO 场景下，它基本帮不上忙。
io_uring：Linux 异步 IO 的救赎
io_uring 是 Linux 5.1 引入的，它彻底改变了异步 IO 的玩法。它的设计思路很巧妙：用两个共享内存的环形队列（Submission Queue 和 Completion Queue），让用户态和内核态之间零拷贝传递 IO 请求和结果。
你想想看，传统系统调用需要陷入内核、拷贝参数、再返回。io_uring 呢？你只需要把请求塞到 SQ 里，然后告诉内核「来活了」。内核处理完后，把结果放到 CQ 里。整个过程，没有系统调用开销（除了提交和收割时的少量 syscall）。
io_uring 核心流程
- 应用程序在 SQ 中写入 IO 请求（读/写/打开/接受等）。
- 调用 io_uring_enter（或使用 SQPOLL 模式让内核自动轮询）。
- 内核处理请求，结果写入 CQ。
- 应用程序从 CQ 中读取完成事件。
我在做消息中间件时，用 io_uring 替换了原来的 epoll + 同步读写。效果很明显：CPU 利用率从 70% 降到了 40%，吞吐量提升了 2 倍。原因很简单，io_uring 把网络 IO 和磁盘 IO 统一成了异步模型，减少了线程切换和内存拷贝。
注意：io_uring 虽然强，但需要内核 5.10+ 才能发挥全部威力。SQPOLL 模式（内核线程自动轮询 SQ）在 5.10 之前有 bug。我曾经在 5.4 内核上踩过坑，SQPOLL 线程会莫名其妙挂掉，导致 IO 请求堆积。
Proactor vs Reactor：选型决策
很多同学问我：到底该用 Proactor 还是 Reactor？我的回答是：看你的 IO 模型和平台。
| 维度 | Reactor | Proactor |
|---|---|---|
| IO 操作主体 | 应用程序（业务线程） | 操作系统（内核） |
| 数据拷贝次数 | 至少 2 次（内核→用户） | 1 次（内核直接到用户缓冲区） |
| 线程模型 | IO 线程 + 工作线程 | 工作线程（IO 由内核完成） |
| 适用场景 | 网络 IO 为主，少量磁盘 IO | 混合 IO（网络 + 磁盘），高并发 |
| 平台支持 | 全平台（epoll/kqueue/select） | Windows（IOCP）、Linux 5.1+（io_uring） |
| 编程复杂度 | 中等 | 较高（需要管理缓冲区生命周期） |
我个人习惯这样选：
- Windows 平台：无脑 IOCP。Windows 的 IOCP 太成熟了，而且 .NET 的异步 IO 底层就是它。
- Linux 平台，纯网络 IO：Reactor（epoll）。io_uring 虽然也能做网络 IO，但 epoll 更轻量，社区生态更成熟。
- Linux 平台，混合 IO（网络 + 磁盘）：io_uring。比如数据库、消息队列、文件服务器，io_uring 能统一 IO 模型，减少线程数。
- 跨平台框架：Reactor。因为 Proactor 在 Linux 上直到 5.1 才真正可用，而 Reactor 在所有平台上都有成熟实现。
我的经验：如果你在做一个全新的 Linux 项目，内核版本能到 5.10+，我建议直接上 io_uring。虽然学习曲线陡一点，但长期来看，它的性能上限比 epoll 高一个量级。而且 io_uring 的接口设计很干净，代码写起来比 epoll 舒服多了。
Proactor 模式的核心架构图
下面这张图展示了 Proactor 模式下，IO 请求从发起到完成的完整流程。注意看，业务线程全程不参与数据拷贝。
总结一下
Proactor 模式的核心优势，是把 IO 操作的等待成本从业务线程转移到了操作系统。你想想看，在 Reactor 模式下，你的业务线程至少要做一次 read/write 系统调用，然后等待数据拷贝完成。而在 Proactor 模式下，这些全由内核代劳了。
但代价也很明显：编程模型更复杂，你需要管理缓冲区的生命周期（因为内核在拷贝数据时，你的缓冲区不能被回收）。而且，不是所有平台都支持真正的异步 IO。
嗯，选型的时候记住一句话：Reactor 适合「IO 就绪通知」，Proactor 适合「IO 完成通知」。如果你的业务逻辑里，数据拷贝是瓶颈，那就上 Proactor。如果瓶颈在业务处理本身，Reactor 就够用了。