性能调优案例3：网络服务器优化，从单线程到Reactor模式
说实话，网络服务器这块，我踩过的坑比吃过的盐还多。早年做嵌入式设备时，一个单线程服务器撑死也就处理几十个连接，稍微有点并发就卡死。后来转到后端开发，发现很多新手还在用那种“来一个连接fork一个进程”的老套路——嗯，不是说不能用，但你要知道，这玩意儿在连接数上千时，光进程切换就能把CPU吃光。
今天咱们就聊聊，怎么把一个简陋的单线程网络服务器，一步步改造成高性能的Reactor模式。我会结合我实际项目中的经验，把那些坑和技巧都抖出来。
1. 单线程模型的痛点
先看一个最原始的服务器模型：
// 单线程阻塞式服务器（伪代码）
while (1) {
int client_fd = accept(listen_fd, ...);
handle_client(client_fd); // 阻塞处理，直到客户端断开
close(client_fd);
}这个模型的问题很明显：一次只能服务一个客户端。如果handle_client里有个耗时的操作（比如读取大文件、调用外部API），后面的客户端就得排队等着。
核心瓶颈：CPU利用率极低，大部分时间花在I/O等待上。说白了，就是CPU在“干等”网卡数据，啥正事也没干。
我在一个物联网项目中就吃过这个亏。当时设备上报数据很频繁，单线程模型下，一个设备的数据还没处理完，其他设备的连接请求就超时了。最后没办法，只能连夜改成多线程——但多线程也有多线程的麻烦。
2. 多线程模型的代价
很多人第一反应是：单线程不行，那就多线程呗。每个连接来一个线程：
while (1) {
int client_fd = accept(listen_fd, ...);
pthread_create(&tid, NULL, handle_client, &client_fd);
}这样确实能同时处理多个连接了。但问题来了：
- 线程创建销毁开销大：每个连接都创建线程，高并发下系统直接崩溃
- 上下文切换频繁：线程数一多（比如上千个），CPU大部分时间都在切换线程，而不是处理业务
- 锁竞争严重：共享资源加锁，性能直线下降
我曾经在一个金融交易系统中，用多线程模型处理3000个并发连接。结果CPU使用率飙到95%，其中60%都花在线程切换上。业务吞吐量反而比单线程还低——这就是典型的“过度设计”。
3. Reactor模式登场
那有没有一种方式，既能处理高并发，又不用创建大量线程？有，就是Reactor模式。
Reactor的核心思想是：事件驱动 + 非阻塞I/O。用一个或少量线程，监听多个文件描述符上的事件（可读、可写、异常等），然后分发到对应的处理函数。
说白了，就是“你准备好了叫我，我再来处理你”。而不是“我一直在你旁边等着你准备好”。
3.1 核心组件
| 组件 | 职责 |
|---|---|
| Reactor | 事件循环，监听所有fd的事件 |
| Acceptor | 处理新连接请求 |
| Handler | 处理具体读写事件 |
| Event Demultiplexer | 多路复用器（select/poll/epoll） |
3.2 流程图
4. 实战：用epoll实现Reactor
我个人习惯用epoll，因为它在高并发场景下比select/poll高效得多。原因很简单：epoll只返回就绪的事件，不用遍历所有fd。
来看一个简化版的实现：
// Reactor核心结构
struct reactor {
int epoll_fd;
struct epoll_event events[MAX_EVENTS];
// 回调函数表
void (*on_accept)(int fd);
void (*on_read)(int fd);
void (*on_write)(int fd);
};
// 事件循环
void reactor_run(struct reactor *r) {
while (1) {
int n = epoll_wait(r->epoll_fd, r->events, MAX_EVENTS, -1);
for (int i = 0; i < n; i++) {
struct epoll_event *ev = &r->events[i];
// 根据事件类型分发
if (ev->events & EPOLLIN) {
if (/* 是监听fd */)
r->on_accept(ev->data.fd);
else
r->on_read(ev->data.fd);
}
if (ev->events & EPOLLOUT) {
r->on_write(ev->data.fd);
}
}
}
}小技巧：epoll的EPOLLET（边缘触发）模式效率更高，但处理起来要小心。我建议新手先用水平触发（LT），稳定后再切边缘触发。我曾经在边缘触发模式下漏处理了一次读事件，导致客户端一直等响应——排查了整整一个下午。
5. 性能对比数据
我在一个压测项目中做过对比，硬件环境是4核CPU、8GB内存，模拟1000个并发连接：
| 模型 | 吞吐量（请求/秒） | CPU使用率 | 内存占用 |
|---|---|---|---|
| 单线程阻塞 | 120 | 15% | 8MB |
| 多线程（每连接一线程） | 850 | 92% | 256MB |
| Reactor（单线程） | 3200 | 68% | 32MB |
| Reactor（多线程+线程池） | 5800 | 85% | 64MB |
看到没？Reactor模式用更少的资源，干更多的活。单线程Reactor的吞吐量是多线程模型的近4倍，但CPU使用率反而更低。为什么？因为省掉了大量的线程切换开销。
6. 避坑指南
我曾经犯过一个低级错误：在事件处理函数里做了阻塞操作（比如调用sleep或等待锁）。结果整个事件循环卡住了，所有连接都超时。记住：Reactor的事件处理函数必须是非阻塞的。如果有耗时操作，要么异步处理，要么扔到线程池里。
另外几个常见坑：
- fd泄漏：每次accept后记得设置非阻塞，否则epoll会出问题
- 事件丢失：边缘触发模式下，一次没读完的数据不会再次触发事件，需要循环读取
- 惊群效应：多线程Reactor中，多个线程同时epoll_wait同一个fd，会导致多个线程被唤醒但只有一个能处理
7. 进阶：多线程Reactor
单线程Reactor虽然好，但遇到CPU密集型任务时，一个核还是不够用。这时候可以升级为多线程Reactor：
// 多线程Reactor架构
// 1个主Reactor负责accept
// 多个子Reactor负责读写事件
void *sub_reactor_thread(void *arg) {
struct reactor *r = (struct reactor *)arg;
reactor_run(r); // 每个子线程运行自己的事件循环
return NULL;
}
int main() {
struct reactor main_reactor;
struct reactor sub_reactors[WORKER_NUM];
// 主Reactor只处理accept
main_reactor.on_accept = distribute_to_sub_reactor;
// 启动子Reactor线程
for (int i = 0; i < WORKER_NUM; i++) {
pthread_create(&tid, NULL, sub_reactor_thread, &sub_reactors[i]);
}
// 主线程运行主Reactor
reactor_run(&main_reactor);
}这种架构下，主Reactor只负责接收新连接，然后把已连接的fd分发给子Reactor。子Reactor各自运行独立的事件循环，互不干扰。这样就能充分利用多核CPU了。
总结一下：从单线程到Reactor，本质上是把“等待”这件事从业务线程中剥离出来，交给操作系统去管理。你想想看，与其让1000个线程各自等数据，不如让1个线程统一等1000个数据——这就是Reactor的精髓。
嗯，关于网络服务器优化，今天就聊到这儿。Reactor模式是高性能网络编程的基石，理解了它，后面学Proactor、协程模型都会轻松很多。
公众号:蓝海资料掘金营，微信deep3321