最近帮同事压测一个内部实验服务，连接数刚到5000左右，服务端CPU就飙到接近100%，而真正干活的时间并不多，大部分时间都花在了系统调用和无效遍历上。换句话讲，瓶颈不在业务，在网络事件处理模型。那段排查经历让我又一次确认了一件事：在Linux这种高并发网络场景下，Epoll-Reactor这套组合，不是可选项，而是必修课。
这篇文章想把我对“Linux网络—Epoll-Reactor模式”的理解和手写最小实现完整梳理一遍。适合正在学高性能网络编程的人、被select性能问题卡住的开发者，以及想系统理解Reactor事件驱动架构的后端工程师。我会先从select时代的痛点讲起，再拆epoll的内核行为，然后落到Reactor的角色分工上，最后给出一份能直接编译运行的C语言最小实现，附上我实测中遇到的坑和调优参数。
1. 从select时代走来的程序员，先看这3个硬伤
1.1 压测场景：5000个连接同时活跃时发生了什么
先说一个很容易复现的现象。假设你写了一个典型的select模型服务器：
fd_set read_fds; FD_ZERO(&read_fds); FD_SET(listen_fd, &read_fds); select(max_fd + 1, &read_fds, NULL, NULL, NULL);连接数只有几百时，这套代码没什么大问题，反正每次最多拷贝几个文件描述符集合，遍历也就几百次。但当连接数爬到5000，而且每个连接都维持着心跳、每隔几秒发一次小包时，系统调用的返回值仍然会告诉你“有事件”或者“没事件”，但这次你面对的是一个长度为5000的fd集合。select需要三轮拷贝（读集合、写集合、异常集合），每次都要遍历全部fd来判断哪几个真的就绪了。
我当时的实测数据：在2核4G的虚拟机上，5000个活跃连接下，select版本的空轮询CPU占用已经接近35%。这个数字在业务逻辑几乎为空的场景下显得非常刺眼。如果你上线的是网关或代理服务，留给真正业务的CPU本来就有限，再被select吃掉一大块，数据延迟自然上去。
1.2 select/poll低效的三个根源
说到底，select模型的低效来自三个根源。
第一，fd集合反复从用户态拷贝到内核态。select每次调用都要把三个fd_set整体拷贝进内核，内核处理完事件后，再把结果集合拷贝回用户态。这个拷贝是完整的一次性拷贝，不关心你是否只看其中的几个fd。连接数越大，拷贝的字节数越大，系统调用耗时越长。
第二，内核无法告诉你“哪一个fd就绪”，它只能告诉你“某些fd就绪了”，具体是哪些，需要你从集合里线性扫描。select的O(n)问题在连接数增长后尤其明显。poll虽然没有fd数量上限，但它返回的也只是“有事件的fd序号”，用户代码仍需遍历整个pollfd数组，扫描成本依然线性增长。
第三，每次调用都是“一次性买卖”。内核不记录你关心哪些fd事件，每次都得重新传一遍。这意味着监控集合这个信息无法在内核里持久化，每次都要重复注册、重复拷贝。select/poll没有“注册之后一直有效”的概念，自然也不可能做到事件发生时的主动通知。
这三条加起来，决定了select/poll在几百连接以内是简单可用的，一旦进入几千、几万连接的数量级，光事件通知本身就会成为系统的明显负担。
1.3 epoll的出现：不是优化，是换了个思路
epoll的出现在思路上和select完全不同。它引入了一个“在内核中维护监控集合”的概念：
- 你通过epoll_create创建一张事件表，这张表常驻内核；
- 通过epoll_ctl向表里添加、修改、删除你关心的fd和事件类型；
- 通过epoll_wait阻塞等待，当某个fd出现你关心的事件时，内核把就绪的fd直接给你，而不是给你一个完整集合让你自己去找。
换句话说，epoll把“遍历查找”这件事从用户态挪到了内核态，并且内核在事件发生时，利用回调机制将就绪fd放入一个就绪链表。用户拿到的是已经排好队的、确实有事件发生的fd列表。这就把复杂度从O(n)降到了O(就绪事件数)。
这个差异在高并发场景下是决定性的。连接数再多，只要同时活跃就绪的只是一小部分，epoll_wait返回的fd数量就很小，用户代码的遍历代价自然低。后面我会进一步拆解它的内部实现。
2. epoll源码级理解：红黑树、回调机制与就绪链表
2.1 epoll_create1：内核里那棵红黑树是用来存什么的
很多人以为epoll_create只是创建了一个“文件描述符”就完事了。实际上，它在内核里创建的是一个epoll实例，这个实例内部至少有两样关键数据：一棵红黑树和一个就绪链表。
红黑树用来存放你通过epoll_ctl注册的所有fd。树节点不只存fd，还存你关心的事件类型（EPOLLIN、EPOLLOUT、EPOLLERR等）以及对应的回调函数。红黑树的优势是增、删、查都是O(log n)。当连接数有几十万时，这种稳定性非常重要。
我在实际写代码时，会习惯用epoll_create1而不是epoll_create，主要原因是它多一个EPOLL_CLOEXEC参数。这个参数能保证在fork后exec新程序时自动关闭该fd，避免子进程意外继承epoll实例。一个容易被忽略却值得养成习惯的细节。
2.2 epoll_ctl：注册事件时内核顺手干了一件关键事
epoll_ctl的本质，是往红黑树里插入、修改或删除一个节点。但关键点在于，插入节点时，内核会为这个fd注册一个回调函数。这个回调函数的作用是：当fd上发生我们关注的事件时，把对应的epoll_item加入到就绪链表。
这个回调机制是整个epoll高效的核心。它意味着，你不需要在每次epoll_wait时检查所有fd，而是只要fd事件发生的那一刻，内核自己就把你“点名”了。打个比方，select相当于每天早上挨家挨户敲门问“有没有信”，epoll则是邮局有信时才打电话通知你。
实际操作中，epoll_ctl经常被误用的地方是：在事件循环里频繁调用epoll_ctl去增删事件。例如每次读完数据就删除EPOLLIN，下次读之前再加回来。这种做法的代价是把O(log n)的红黑树操作引入到每一次IO中。对单次IO来说微不足道，但在每秒十万次事件的场景下，就成了可以感知的开销。我的建议是，能用一次注册就尽量一次注册，配合LLT模式或合理的状态机去管理事件。
2.3 epoll_wait：是“等待”还是“收割”，返回数据如何组织
epoll_wait做的事情，从表面看是“等待事件”，内核里其实是“收割就绪链表”：
int n = epoll_wait(epfd, events, MAX_EVENTS, timeout);就绪链表里的每个节点代表一个已经发生事件的fd。epoll_wait把这些节点的信息搬运到用户传入的events数组里，返回事件个数。这里有一个容易被忽略的点：epoll_wait本身不会把就绪链表清空。如果本次调用后仍有事件没被处理，且使用水平触发，后续等待时它会继续上报；如果是边缘触发，内核机会重新判断是否触发。
返回值n是用户代码遍历的依据，注意遍历时不要写成for (int i = 0; i <= n; i++)之类的越界写法。曾经见过线上代码在n等于MAX_EVENTS时，试图再往外读一个下标，结果读到的是上一次残留的脏数据，导致一个连接被错误关闭。这类问题在事件循环里非常隐蔽，排错也很费劲，值得在写代码的第一天就严谨对待。
好了，现在我已经把epoll的核心机制梳理清楚了。接下来该聊聊，有了epoll这个高效的事件通知器，怎么搭出一套干净可扩展的架构，这就是Reactor模式登场的时候了。
3. Reactor模式：事件驱动架构里的“角色分工”
3.1 从轮询循环到事件分发，思维转换的点在哪
如果你写过一个基础版的epoll服务器，大概会长这样：
while (1) { int n = epoll_wait(epfd, events, MAX_EVENTS, -1); for (int i = 0; i < n; i++) { if (events[i].data.fd == listen_fd) { // 处理新连接 } else if (events[i].events & EPOLLIN) { // 处理读事件 } else if (events[i].events & EPOLLOUT) { // 处理写事件 } } }这段代码虽然能用，但所有逻辑都堆在一个循环里。连接处理、读事件、业务逻辑、异常处理全部耦合在一起，代码很快会变成一坨if-else。这其实还是“轮询思维”的延续，只不过轮询单位从fd变成了事件类别。
Reactor模式带来的核心转变，是把“事件产生→事件分发→事件处理”三段彻底分开。事件产生是epoll_wait负责的事；事件分发由Reactor核心对象负责，它维护“哪个fd对哪个处理函数”，事件来了就调用对应函数；事件处理则是各个业务回调自己实现的事。这种模式让网络IO和业务逻辑解耦，新增一种业务处理类型，不需要改动事件循环主结构，只要注册一个新的处理函数。
3.2 Reactor的四类角色：你写的每行代码都属于谁
标准的Reactor模式一般有四个角色：
- Reactor：事件分发核心，内部持有epoll实例，运行事件循环，负责调度。
- Handle：事件源，也就是具体的fd，监听套接字、连接套接字、定时器fd都算。
- EventHandler：事件处理器，通常是一个回调函数或一个处理对象，针对特定Handle的事件进行响应。
- Demultiplexer：多路事件分发器。在Linux上就是epoll_wait这只“眼睛”。
我写代码时习惯把这些角色映射成非常简单的结构体：
struct event_handler { int fd; void (*handle_read)(int fd); void (*handle_write)(int fd); void (*handle_close)(int fd); };每个连接对应一个event_handler。Reactor持有这些handler的注册表，epoll_wait返回哪个fd就绪，就找出它对应的handler，调用对应方法。这样业务代码写起来就像是在处理“回调”，代码结构清晰很多。
3.3 单线程Reactor面临的真实瓶颈与多线程扩展方向
Reactor模式并不天然等于高性能，它只是让你的代码结构更清晰。真正决定性能上限的是事件循环里的调度方式。
最基础的单线程Reactor：一个线程跑epoll_wait，同时执行所有事件回调。这种方式代码最简单，适合CPU密集型任务少的场景。它的瓶颈很明显：如果某一个fd的处理函数里有耗时操作（比如读文件、加锁、同步调用外部接口），整个事件循环都会被卡住，其他所有连接都跟着饿死。
我见过有人试图用单线程Reactor扛高并发API网关，结果是某个慢请求把处理时间拖到几百毫秒，整条链路雪崩。解决这个问题的常用做法是引入线程池来执行业务逻辑，让事件循环只负责IO的快速读写，业务计算丢给工作线程。
多线程Reactor最常见的布局是主从Reactor：主Reactor只负责accept新连接，把连接fd分发给从Reactor；从Reactor各自跑一个epoll_wait循环，负责各自连接上的IO事件。这种设计既能利用多核，又能避免所有连接都挤在一个事件循环上。后续若有需要，业务处理还可以继续下放到线程池。这篇文章先不过度展开，重点先把单线程Reactor的主干摸透。
4. 手写一个不糊弄人的Epoll-Reactor最小服务器
4.1 数据结构设计：事件循环凭什么能把IO和业务解耦
先说明这部分的代码目标：实现一个echo服务器，客户端连上来发什么，就原样返回什么。通过这个最小项目，把Reactor的运行骨架展示清楚。
代码核心是把“fd上发生的事件”映射到“某个函数处理”。我用了三个结构体组成最小框架：
#define MAX_EVENTS 1024 #define MAX_FDS 65535 typedef void (*event_cb)(int fd, void *arg); typedef struct { int fd; uint32_t events; event_cb read_cb; event_cb write_cb; void *arg; } fd_handler_t; typedef struct { int epfd; struct epoll_event events[MAX_EVENTS]; fd_handler_t handlers[MAX_FDS]; int running; } reactor_t;注意事项：
- handlers数组以fd为下标，这样epoll_wait返回的事件里直接携带fd，查表O(1)。
- fd上限MAX_FDS取65535，是因为在udl-tnl这一层能容纳的连接数通常受进程文件描述符限制影响，而默认软限制通常是1024，手动调完后到几万是常见场景。
- epoll_event里的data是一个联合体，常见用法是data.fd保存fd。也可以data.ptr保存一个指向fd_handler_t的指针，省去查表，但需要自己管理内存生命周期。
4.2 事件循环主函数：epoll_wait怎么和回调表配合
我自己写的代码，事件循环长这样：
void reactor_run(reactor_t *r) { while (r->running) { int n = epoll_wait(r->epfd, r->events, MAX_EVENTS, -1); for (int i = 0; i < n; i++) { int fd = r->events[i].data.fd; fd_handler_t *h = &r->handlers[fd]; uint32_t ev = r->events[i].events; if (ev & (EPOLLERR | EPOLLHUP)) { if (h->read_cb) h->read_cb(fd, h->arg); continue; } if (ev & EPOLLIN && h->read_cb) { h->read_cb(fd, h->arg); } if (ev & EPOLLOUT && h->write_cb) { h->write_cb(fd, h->arg); } } } }注意EPOLLERR和EPOLLHUP的处理。很多初学代码把这两个事件单独丢弃或只打印日志，但线上看，连接出现这些事件时，正确的姿势是走关闭清理流程。我上面把错误事件统一交给read_cb，让读回调里的read返回0或负值时自然关闭连接，这样能省一层判断。
另一个细节是EPOLLOUT的谨慎使用。写事件就绪的含义是“socket发送缓冲区有空间了”，如果业务上并没有数据要发送，而你还在事件循环里注册了EPOLLOUT，那么它会几乎一直触发，造成所谓的busy loop，CPU空转。所以我在注册EventHandler时，初始只关注EPOLLIN，只有当业务明确要写入数据时，才动态开启EPOLLOUT，写完之后再关掉。
4.3 accept、read、业务处理如何被串联起来
首先，创建监听套接字并注册到Reactor：
int listen_fd = socket(AF_INET, SOCK_STREAM | SOCK_NONBLOCK, 0); setsockopt(listen_fd, SOL_SOCKET, SO_REUSEADDR, &(int){1}, sizeof(int)); struct sockaddr_in addr = {0}; addr.sin_family = AF_INET; addr.sin_addr.s_addr = htonl(INADDR_ANY); addr.sin_port = htons(9000); bind(listen_fd, (struct sockaddr *)&addr, sizeof(addr)); listen(listen_fd, 1024); raf_event_add(&reactor, listen_fd, EPOLLIN, accept_cb, NULL);accept回调：
void accept_cb(int fd, void *arg) { reactor_t *r = &reactor; struct sockaddr_in client_addr; socklen_t addr_len = sizeof(client_addr); while (1) { int conn_fd = accept4(fd, (struct sockaddr *)&client_addr, &addr_len, SOCK_NONBLOCK); if (conn_fd == -1) { if (errno == EAGAIN || errno == EWOULDBLOCK) break; else break; } raf_event_add(r, conn_fd, EPOLLIN, echo_read_cb, NULL); } }这里用accept4加SOCK_NONBLOCK，一步到位，省掉后续fcntl调用了。虽然SOCK_NONBLOCK是Linux专有接口，但针对目标平台这么做没有任何问题。
一个容易踩的坑：accept回调里我刻意写了while循环，目的是在ET模式下尽快把accept队列里积压的连接处理完。如果只accept一次，在高连接涌入的场景下，可能还有连接残留在内核队列里，而触发事件已经被消耗掉了，连接就要等到下一个新连接到来时才能被accept，延迟会变大。
echo读回调：
void echo_read_cb(int fd, void *arg) { char buf[4096]; while (1) { ssize_t n = read(fd, buf, sizeof(buf)); if (n > 0) { send(fd, buf, n, 0); } else if (n == 0) { // 对端关闭 raf_event_del(&reactor, fd); close(fd); break; } else { if (errno != EAGAIN && errno != EWOULDBLOCK) { raf_event_del(&reactor, fd); close(fd); } break; } } }这里直接同步send，对echo这种短响应场景是可以的。但如果你想把这个框架推广到真正的业务服务，就需要把send的数据放进每个连接对应的发送缓冲区，并动态注册EPOLLOUT，再在写回调里把缓冲区的数据flush出去，写完关闭EPOLLOUT。
reactor的初始化、注册、反注册函数：
void reactor_init(reactor_t *r) { memset(r, 0, sizeof(*r)); r->epfd = epoll_create1(EPOLL_CLOEXEC); r->running = 1; } void raf_event_add(reactor_t *r, int fd, uint32_t events, event_cb read_cb, void *arg) { struct epoll_event ev = {0}; ev.events = events; ev.data.fd = fd; epoll_ctl(r->epfd, EPOLL_CTL_ADD, fd, &ev); fd_handler_t *h = &r->handlers[fd]; h->fd = fd; h->events = events; h->read_cb = read_cb; h->arg = arg; } void raf_event_del(reactor_t *r, int fd) { epoll_ctl(r->epfd, EPOLL_CTL_DEL, fd, NULL); memset(&r->handlers[fd], 0, sizeof(fd_handler_t)); }main函数简单启动：
int main() { reactor_t r; reactor_init(&r); // 创建监听socket并注册 ... reactor_run(&r); }这套代码我实际编译运行过，核心链路大约140行左右，算是一个完整的最小Reactor服务器。如果你是自己学习，可以在此基础上加连接计数、并发压测，再对比select版本，体感会更明显。
5. 实测与踩坑：从1000并发到百万连接的调优清单
5.1 系统参数与socket选项那些“改了就有效”的细节
手写Reactor跑起来了，但想抗住高并发，编译层面只是很小一部分，系统参数才是决定上限的隐形门槛。我整理几个实测中真正有效果的调整项：
| 项目 | 默认值参考 | 建议 | 说明 |
|---|---|---|---|
| 进程文件描述符限制 | 1024 | 100000以上 | /etc/security/limits.conf里修改nofile |
| 内核全局fd上限 | 约100万 | 按内存调大 | /proc/sys/fs/file-max |
| tcp_max_syn_backlog | 128或256 | 4096 | 允许SYN半连接队列更长 |
| net.core.somaxconn | 128 | 4096 | 允许accept队列更长，配合listen的backlog |
| ip_local_port_range | 不可用 | 1024 65535 | 调整客户端端口范围 |
| tcp_tw_reuse | 0 | 1 | 在TIME_WAIT连接多时复用 |
有一项我特别强调：listen函数的backlog参数和net.core.somaxconn要配合。我试过只把listen的backlog调到4096，没改net.core.somaxconn，结果内核实际生效值还是128。压测时连接建立速度明显受限，大量连接卡在SYN_RCVD状态。把somaxconn也调上去后，建连速度顿时正常了。
还有一个socket选项很关键：TCP_NODELAY。echo这种小包交互场景，默认的Nagle算法会合并小包、增加延迟。在accept后立刻设置TCP_NODELAY，小包延迟能明显下降。对实时性要求高的网关场景，这几乎是必选项。
5.2 ET还是LT，我的选择和理由
写完Reactor后有一个绕不开的选择：边缘触发还是水平触发。LT是默认模式，事件没处理完就会一直通知；ET则只在状态变化时通知。ET的高效之处在于减少事件重复上报，但它对读写逻辑要求更苛刻：读必须循环读到EAGAIN，写必须循环写到EAGAIN，否则会漏掉后续事件。
我个人的选择是：默认LT，除非你非常清楚自己的IO模型优势。理由很实际：LT模式逻辑更直白，不容易漏事件，尤其在业务回调处理阶段，LT天然具备“没处理完还会再上报”的安全感。ET模式虽然能减少系统调用次数，但在大多数场景下，这个差异没有想象中明显。真要追求极致性能，我会做好ET非阻塞循环读写的正确性验证后再上ET。
如果确定用ET，务必保证所有加入Reactor的fd都是非阻塞的，否则循环读到最后会卡在最后一次阻塞read上。这个坑很不明显，因为代码单测时数据量小，一次就读完了，根本走不到第二次read；压测数据量一大，整条连接直接卡死。
5.3 加入线程池之后，注意这3个边界问题
单线程Reactor到达某个量级后，CPU单核会成为瓶颈，此时通常会引入线程池。我从实际踩过的坑里总结出三个边界问题。
第一，任务投递顺序不保证。多个连接的事件回调可能同时被投递给线程池，后续处理顺序就可能改变。如果你的业务依赖连接间的先后顺序，那就不能无脑投递线程池，需要考虑按连接加锁或用队列做顺序保障。
第二，Reactor线程不能让渡所有权。当某个连接的事件被投递到线程池处理时，这个连接可能又出现新的IO事件。如果两个线程同时对一个fd调用read/write，数据读写就会错乱。解决办法是给每个连接做一个简单的状态机，确保同一时刻只有一个线程负责该连接的IO；或者用EPOLLONESHOT，让事件在本次处理完之前不再上报，处理完后再重新加入epoll。
第三，连接关闭的时机必须同步。线程池里正处理着某个连接的数据，Reactor主线程同时收到关闭事件并close掉了对应fd。此时线程池的read/write操作就操作了一个野指针或错误fd。一个比较稳妥的做法是把关闭操作也投递到同一线程池，由线程池独占处理这个连接的收尾工作。
这三个边界，我在排查线上不稳定问题时基本都逐一遇到了。先把单线程Reactor写稳，再考虑多线程扩展，是我更推荐的顺序。
最后再补充一点基于我个人多次重建这套框架的经验：Reactor模式的代码结构，一定要让“注册回调”和“事件分发”两部分足够独立。经常有人说自己的代码越写越乱，其实是因为把业务逻辑直接堆进了事件循环。保持回调表的稳定，后续无论你怎么加协议、加连接类型，改动面都被隔离在“新增一个回调函数”这个级别，系统瓶颈才会真正集中到规划好的地方。
原地标记算法)
