Proactor模式：从原理到实战

说实话，我第一次接触Proactor模式时，脑子里全是问号。那时候我在做一个高并发文件服务器，Reactor模式跑得好好的，为什么要换？直到我遇到了磁盘I/O这个瓶颈——CPU在等磁盘，线程在等CPU，整个系统像堵车一样。嗯，今天我们就来聊聊这个让我「顿悟」的设计模式。

Proactor模式的核心思想

Proactor模式，说白了就是「你告诉我干啥，干完了通知我」。它和Reactor最大的区别在于：谁来做实际的I/O操作。

• Reactor模式：事件循环告诉你「可以读了」，你自己去读
• Proactor模式：你告诉系统「帮我读这些数据」，读完了通知你

我个人习惯把Proactor理解为「异步委托」。你把任务交给操作系统，然后该干嘛干嘛，等结果回来再处理。这就像你点外卖——不用自己做饭，等外卖到了吃就行。

异步I/O（AIO）基础

要实现Proactor模式，底层必须依赖操作系统的异步I/O能力。Linux和Windows在这块差别很大，我踩过不少坑。

Windows的IOCP

Windows的IOCP（I/O Completion Port）是Proactor模式的经典实现。它原生支持异步读写，你只需要提交一个OVERLAPPED结构，系统完成后会把结果投递到完成端口。

// Windows IOCP 异步读示例
HANDLE hFile = CreateFile(
    L"data.bin",
    GENERIC_READ,
    FILE_SHARE_READ,
    NULL,
    OPEN_EXISTING,
    FILE_FLAG_OVERLAPPED,  // 关键：必须使用重叠标志
    NULL
);

OVERLAPPED ov = {0};
ov.Offset = 0;
ov.hEvent = CreateEvent(NULL, TRUE, FALSE, NULL);

char buffer[1024];
BOOL ret = ReadFile(hFile, buffer, sizeof(buffer), NULL, &ov);

if (ret == FALSE && GetLastError() == ERROR_IO_PENDING) {
    // 读操作已提交，等待完成
    WaitForSingleObject(ov.hEvent, INFINITE);
    DWORD bytesRead;
    GetOverlappedResult(hFile, &ov, &bytesRead, FALSE);
}

我在做Windows下的游戏服务器时，就用IOCP处理所有网络和文件I/O。一个工作线程池轮询完成端口，效率非常高。

Linux的AIO

Linux的AIO（POSIX AIO）就没那么友好了。我记得第一次用的时候，发现它其实是用户态线程模拟的，真正的内核级异步I/O直到io_uring才成熟。

// Linux POSIX AIO 示例
#include <aio.h>

struct aiocb cb;
memset(&cb, 0, sizeof(cb));
cb.aio_fildes = fd;
cb.aio_buf = buffer;
cb.aio_nbytes = sizeof(buffer);
cb.aio_offset = 0;
cb.aio_sigevent.sigev_notify = SIGEV_THREAD;
cb.aio_sigevent.sigev_notify_function = completion_handler;

int ret = aio_read(&cb);
if (ret != 0) {
    perror("aio_read failed");
    return;
}

// completion_handler 会在读完成后被调用
void completion_handler(sigval_t sigval) {
    struct aiocb *req = (struct aiocb *)sigval.sival_ptr;
    ssize_t bytes = aio_return(req);
    printf("Read %zd bytes\n", bytes);
}

Proactor模式的架构设计

一个完整的Proactor框架通常包含这几个角色：

• Proactor：核心调度器，负责提交异步操作和分发完成事件
• AsyncOperation：异步操作对象，封装了I/O请求和回调
• CompletionHandler：完成处理器，操作完成后被调用
• Service：具体的I/O服务（读、写、连接等）

下面这张图展示了Proactor模式的核心流程：

Proactor vs Reactor：怎么选？

你可能会问：那我到底该用哪个？我个人的经验是：

场景	推荐模式	原因
网络I/O密集（如Web服务器）	Reactor	网络I/O延迟低，Reactor的事件驱动更轻量
文件I/O密集（如数据库、日志系统）	Proactor	文件I/O延迟高，异步操作能充分利用等待时间
混合场景（如代理服务器）	两者结合	网络用Reactor，文件用Proactor
Windows平台	Proactor（IOCP）	Windows原生支持，性能最佳
Linux平台（新内核）	Proactor（io_uring）	io_uring性能远超传统epoll

一个简单的Proactor实现框架

下面我用C语言写一个极简的Proactor框架，帮你理解核心逻辑：

// proactor.h - 极简Proactor框架
#ifndef PROACTOR_H
#define PROACTOR_H

#include <stdint.h>
#include <stddef.h>

// 异步操作类型
typedef enum {
    OP_READ,
    OP_WRITE,
    OP_ACCEPT,
    OP_CONNECT
} op_type_t;

// 异步操作结构
typedef struct async_op {
    op_type_t type;
    int fd;
    void *buf;
    size_t count;
    size_t offset;
    void (*callback)(struct async_op *op, ssize_t result);
    void *user_data;
} async_op_t;

// Proactor 核心结构
typedef struct proactor proactor_t;

// 创建Proactor实例
proactor_t* proactor_create(void);

// 提交异步读操作
int proactor_read(proactor_t *p, int fd, void *buf, 
                  size_t count, size_t offset,
                  void (*cb)(async_op_t*, ssize_t),
                  void *user_data);

// 提交异步写操作
int proactor_write(proactor_t *p, int fd, void *buf,
                   size_t count, size_t offset,
                   void (*cb)(async_op_t*, ssize_t),
                   void *user_data);

// 事件循环（阻塞）
void proactor_run(proactor_t *p);

// 销毁Proactor
void proactor_destroy(proactor_t *p);

#endif

这个框架的核心思想是：把I/O操作封装成对象，提交给Proactor，Proactor负责调度和回调。实际实现中，你需要根据平台选择底层机制（IOCP、io_uring或POSIX AIO）。

实战中的坑与经验

最后分享几个我踩过的坑：

• 缓冲区生命周期管理：异步操作完成前，缓冲区不能被释放或重用。我见过一个同事在栈上分配缓冲区然后提交异步读，结果回调时栈数据已经没了。
• 回调线程安全：Proactor的回调可能在任何线程中执行。如果你的回调里操作了共享数据，记得加锁或用无锁队列。
• 错误处理要全面：异步操作可能因为各种原因失败（文件被删除、磁盘满、权限不足）。每个回调里都要检查result值。
• 不要阻塞回调：回调函数应该快速返回，不要在里边做耗时操作。否则会阻塞后续完成事件的投递。

Proactor模式虽然比Reactor复杂一些，但它在处理高延迟I/O时的优势是无可替代的。你想想看，当你的服务器需要同时处理一万个文件读取请求时，每个请求都开一个线程去等，那得多少线程？Proactor用几个线程就能搞定，这就是它的价值所在。

---