搞 Linux 网络编程的人，早晚都会撞上“百万级并发”这个词。面试要聊、压测要跑、真正的线上流量高峰也在考人。我早年在某内部系统上做长连接服务，一开始很天真，一个连接开一个线程，数据量稍微上来，整个进程直接卡到没法看。后来把模型改成 Reactor，同样的物理机，连接数从千级一路压到了几十万，配合系统参数调整甚至可以接近百万。这篇文章不写长编大论，我把 Reactor 网络模型的原理、手写代码、系统调优和踩坑过程全部拆开讲，适合刚接触高并发网络编程的同学，也适合已经写过 epoll 但还想继续压榨单机性能的开发者。
1. 为什么高并发网络服务离不开 Reactor
1.1 传统阻塞 IO 的连接困境
先看一段最朴素的网络服务写法：
int lfd = socket(AF_INET, SOCK_STREAM, 0); bind(lfd, ...); listen(lfd, 64); while (1) { int cfd = accept(lfd, NULL, NULL); pthread_t tid; pthread_create(&tid, NULL, handle_client, &cfd); }这个模式很好理解：来一个连接，开一个线程去处理。问题是，线程不是免费资源。每个线程默认栈空间 8MB，那是虚拟内存，真正让你肉疼的是线程调度。假设你开了 1 万个线程，内核就得在这 1 万个可运行实体之间来回切换，CPU 大部分时间都耗在上下文切换上，而不是在处理业务。
更尴尬的是，绝大多数网络连接处于空闲状态。一个客户端连上来，可能几秒甚至几十秒才发一条心跳。用阻塞 IO 加线程去等数据，等于大堂里站了几万个服务员，每人只负责盯着一桌客人，客人不举手就干站着。你想想这个画面，就知道资源浪费有多离谱。后来圈子里常说的 C10K 问题，指的就是一台服务器能不能稳定扛住上万个并发连接。用“一个连接一个线程”的老写法，基本上到几千个连接就会闻到焦味。
1.2 事件驱动：把“等”从业务线程里拿掉
既然连接大多空闲，那就不该让线程傻等。正确的思路是：让内核替我们盯着所有连接，哪个连接有数据可读了、可以写入了、对方关闭了，内核再通知我们。这就是所谓的事件驱动。
用一个非阻塞的调用把“等待数据到达”这件事打包给操作系统，业务线程只处理那些真正有数据的连接。没有事件的时候，线程可以去忙别的事，或者干脆睡觉。这样，一万个连接可能只有几十个是活跃的，那你只需要处理几十个活跃对象，而不是让一万个线程全部待命。
我之前跟人解释这个转变，喜欢拿咖啡馆举例。阻塞模型是每个客人配一个咖啡师，客人不来点单，咖啡师就只能杵着。事件驱动模型是店里就一两个咖啡师来回转，哪个客人举手了就去招呼哪个。你可能会想“那忙不过来怎么办”，这就是后面要说的多线程 Reactor 和任务队列的用武之地。
1.3 Reactor 模型画像
Reactor 翻译过来是“反应堆”，其实可以不那么玄乎。它就是一套“循环等待事件 + 事件分发 + 事件处理”的框架。核心组件就三类：
- 事件循环：不停调用内核的 IO 多路复用接口，拿到就绪事件列表。
- 事件分发器：根据事件类型，决定调用哪个处理函数。
- 事件处理器：真正读写数据、处理业务逻辑的代码。
一个最小化的 Reactor 模型大概长这样：
while (1) { int n = epoll_wait(epfd, events, MAX_EVENTS, -1); for (int i = 0; i < n; i++) { dispatch(events[i]); // 分发事件 } }epoll_wait负责“等”，dispatch负责“分”，剩下的业务代码全部塞进处理函数里。这套模型迷人之处在于：事件循环只有一套，但它可以服务几十万个连接。连接本身不再占用线程，只占用一个注册在内核里的事件记录。等到某个 fd 上真的有数据了，它才短暂地走进业务线程的视野。
你可能听说过分 Reactor 和主从 Reactor 之类的变种，本质上都是这个思想的延伸。单 Reactor 适合 CPU 密集型业务比重低的场景，多 Reactor 适合把 accept、IO、业务处理彻底拆开。先把这个基础模型吃透，后面所有变化都好理解。
2. Reactor 核心组件拆解与选型思路
2.1 事件循环：服务端的“心脏”
事件循环是整个服务里最重要的一环。它不能停，停了整个服务就死了。它也不能慢，慢了所有连接都跟着排队。
事件循环通常由三件事组成：获取事件、解析事件、分发事件。以下面这段代码为例：
while (!stop) { int n = epoll_wait(epfd, events, MAX_EVENTS, -1); if (n < 0) { if (errno == EINTR) continue; break; } for (int i = 0; i < n; i++) { struct epoll_event *ev = &events[i]; if (ev->data.fd == listen_fd) { handle_accept(listen_fd); } else if (ev->events & EPOLLIN) { handle_read(ev->data.fd); } else if (ev->events & EPOLLOUT) { handle_write(ev->data.fd); } else { handle_close(ev->data.fd); } } }epoll_wait的 timeout 参数我建议不要随便传 0。传 0 是轮询模式，事件循环会疯狂空转，白白烧掉 CPU。生产环境绝大多数场景传 -1 或者一个合理的超时时间，比如 100ms，既能及时响应事件，又不会把 CPU 跑满。
事件循环最怕的是某个 handler 里做了阻塞操作。比如直接在读事件里查数据库，查了 5 秒才返回，那这 5 秒里所有新连接都进不来，已有的连接数据也没人读。这个老生常谈，但几乎每隔一段时间就会有人踩一次。
2.2 epoll 为什么是百万级并发的理想搭档
要支撑百万级并发，事件通知机制必须先过关。Linux 上主要有 select、poll、epoll 三套接口，差异非常大：
| 机制 | 复杂度 | 最大连接数 | 事件获取方式 | 内核实现 |
|---|---|---|---|---|
| select | O(n) | FD_SETSIZE 限制，通常 1024 | 每次调用都要遍历全部 fd | 用户态拷贝 fd 集合到内核 |
| poll | O(n) | 可突破 1024，但仍是全量扫描 | 每次调用都要遍历全部 fd | 同样全量扫描，无差别 |
| epoll | O(1) | 取决于系统内存与 fd 上限 | 只返回有事件发生的 fd | 内核维护红黑树与就绪链表 |
select 每次调用都要把几十万个 fd 从用户态拷贝进内核，内核再把它们全部扫一遍，这个开销太大。poll 解决了 fd 数量限制，但没有解决效率问题，不断增大的集合会让每次调用都越来越慢。
epoll 的高明之处在于：它把需要关心的 fd 通过epoll_ctl提前告诉内核，内核用红黑树维护这些 fd，并且把真正发生事件的 fd 挂到一个就绪链表上。你调用epoll_wait时，只是把这个就绪链表拿回去。绝大多数连接空闲时，这个链表可能为空，epoll_wait一下就返回了。这就让“百万 fd 在线，但只有少量活跃”成为可能。
2.3 Handler 与事件分发器的组织方式
事件分发器的职责就是“路由”。你注册一个 fd 的读事件，那么当这个 fd 可读时，分发器要找到对应那个读函数并调用它。最简单的做法是用结构体记录：
typedef void (*event_callback)(int fd, void *args); struct event_item { int fd; int mask; // EPOLLIN / EPOLLOUT / EPOLLERR event_callback read_cb; event_callback write_cb; void *args; };每次epoll_ctl注册事件时，把struct epoll_event.data.ptr指向这个结构体，这样在事件循环里拿到data.ptr就能直接找到回调函数。这个设计的好处是：事件循环代码完全不用关心业务细节，它只负责把事件交给对应的 handler。以后想扩展 UDP 事件、信号事件、定时器事件，都可以挂在这套分发机制上。
我见过有人把业务逻辑直接写在事件循环的大 switch 里，几十个分支堆在一起，维护起来非常痛苦。Handler 隔离做得好的代码，新增一个连接类型通常只需要新增一个 handler，不改事件循环。这一点百万级并发下尤其重要，因为你不可能每次都停机去改主循环。
3. 从零实现一个轻量级 Reactor，核心代码逐段拆解
3.1 初始化 epoll 实例与监听流程
先创建 epoll 实例和监听 socket：
int epfd = epoll_create1(0); int lfd = socket(AF_INET, SOCK_STREAM, 0); int opt = 1; setsockopt(lfd, SOL_SOCKET, SO_REUSEADDR, &opt, sizeof(opt)); struct sockaddr_in addr; addr.sin_family = AF_INET; addr.sin_addr.s_addr = htonl(INADDR_ANY); addr.sin_port = htons(8080); bind(lfd, (struct sockaddr *)&addr, sizeof(addr)); listen(lfd, 4096); struct epoll_event ev; ev.events = EPOLLIN; ev.data.fd = lfd; epoll_ctl(epfd, EPOLL_CTL_ADD, lfd, &ev);这里我有三个建议：
第一，epoll_create1(0)比老的epoll_create(size)更推荐，那个 size 其实已经没意义了，干脆用新接口。第二，SO_REUSEADDR一定要加，否则服务重启时端口还在 TIME_WAIT 状态，端口直接绑定失败。第三，listen的 backlog 不要随手写 64，要结合后面的net.core.somaxconn参数，稍大一些可以减少高并发下连接被内核丢弃的概率。
3.2 事件循环的主体逻辑实现
事件循环就是前面贴过的那段。我再补充几个容易被忽略的细节：
epoll_wait返回的事件数组长度，其实是已经就绪的事件数，同一个 fd 可能在返回列表里出现多次，因为它在一次epoll_wait中可能会同时触发读、写、错误多种事件。所以不要只处理一个分支就结束，要按位检查EPOLLIN、EPOLLOUT、EPOLLERR、EPOLLHUP。
当 fd 被对端关闭，通常会同时返回EPOLLIN和EPOLLRDHUP。我建议显式处理EPOLLRDHUP，这样能较早知道对端关闭了连接，避免再去读一次返回 0 才发现。在超大规模连接下，少一次无谓的 read 就能省下不少系统调用。
3.3 连接接入与读事件处理的完整示例
新连接到达时，监听 fd 上会触发可读事件。处理函数这么写：
void handle_accept(int lfd) { while (1) { int cfd = accept4(lfd, NULL, NULL, SOCK_NONBLOCK | SOCK_CLOEXEC); if (cfd < 0) { if (errno == EAGAIN) break; break; } struct epoll_event ev; ev.events = EPOLLIN | EPOLLET; ev.data.fd = cfd; epoll_ctl(epfd, EPOLL_CTL_ADD, cfd, &ev); } }这里用了accept4，直接给新 fd 设置了非阻塞和CLOEXEC。非阻塞能避免读事件触发后数据没读完导致线程卡住，CLOEXEC防止exec后 fd 泄漏。循环 accept 的原因是：监听 fd 可读时可能不止一个连接在等待，必须一直 accept 到EAGAIN，否则会漏掉连接。
读事件处理比较谨慎：
void handle_read(int fd) { char buf[4096]; while (1) { ssize_t n = read(fd, buf, sizeof(buf)); if (n > 0) { process(buf, n); } else if (n == 0) { close(fd); break; } else { if (errno == EAGAIN) break; close(fd); break; } } }这段代码在边缘触发模式下是标准写法：循环读，读到返回 0 表示对端关闭，读到EAGAIN表示当前数据已经读完了。如果你用水平触发模式，其实不读干净也没关系，内核会不断通知你；但边缘触发模式下漏读可能真的会丢事件。
3.4 一个可直接复制的 Echo 服务演示
把以上代码组合起来，就是一个最简单的 Echo 服务：客户端发什么，服务端原样回什么。关键模块就是事件循环加 accept、read、write 三个函数。你甚至可以只保留读事件，把业务解析写在process里，再通过epoll_ctl修改事件为EPOLLOUT，然后在写事件里回包。
这里有一个我在早期经常犯的错：服务端往客户端写数据时，不能保证一次write就能写完。TCP 是有窗口的，窗口满了write可能只写入一部分。正确做法是准备一个写缓冲区，没写完的数据挂到EPOLLOUT事件上，等 socket 可写时继续写。很多从 BIO 转过来的同学往往默认write一定写完整，结果线上出现丢包或者连接异常关闭。
4. 百万级并发的系统级调优：参数与估算
4.1 文件描述符上限与 ulimit 调整
一百万连接就意味着至少需要一百万个 fd，每个连接至少占用一个 fd。如果系统或进程的 fd 上限只有几万，那模型再优雅也白搭。
先看两个层面的限制：
cat /proc/sys/fs/file-max # 系统级 fd 总量上限 ulimit -n # 当前 shell 进程的 fd 上限进程级限制可以用ulimit -SHn 1048576调整，更持久的方式是写到/etc/security/limits.conf里。如果服务是通过 systemd 管理的，还要检查服务配置里的LimitNOFILE，默认值往往只有 1024 或 4096，要显式调大。
这时候也有个容易被忽略的问题：file-max的值不是越大越好，它是整个系统所有进程加起来的总上限。单机服务如果独享，可以按内存来估算，设到两三百万比较稳妥。
4.2 连接内存估算：一百万连接到底吃了多少内存
既然要撑百万连接，先回答一个问题：内存够不够。每个 TCP 连接在内核里都有对应的 socket 结构，还要分配发送缓冲区、接收缓冲区。常用默认值可以先看：
cat /proc/sys/net/ipv4/tcp_rmem cat /proc/sys/net/ipv4/tcp_wmem这些值通常是一个范围内的三个数字，比如4096 87380 6291456，分别表示最小值、默认值、最大值。实际占用还会随流量动态增长。我做过一个粗糙的估算：
| 内存项 | 单连接估算 | 100 万连接总量 |
|---|---|---|
| 内核 socket 结构体 | 约 1~3 KB | 1~3 GB |
| 接收/发送缓冲区 | 各 4~16 KB | 1~3 GB |
| 用户态连接对象 | 约 0.5~2 KB | 0.5~2 GB |
| 其他临时开销 | 约 1 KB | 1 GB |
所以百万连接至少准备 4~6 GB 可用内存，如果服务本身还要缓存业务数据，那还要额外算。这个数字不小，但现代服务器动辄几十上百 GB 内存，内存通常不是第一个瓶颈。
4.3 TCP 内核参数与连接管理调优
高并发短连接场景最容易出现一堆TIME_WAIT状态的连接，因为它们无法立刻释放端口。常见的调整参数有这么几个：
| 参数 | 作用 | 我常用的推荐值 |
|---|---|---|
net.ipv4.tcp_tw_reuse | 允许将TIME_WAIT连接复用为新连接 | 1 |
net.ipv4.tcp_max_tw_buckets | 限制系统同时存在的TIME_WAIT数量 | 200000 |
net.core.somaxconn | listen的 backlog 上限 | 65535 |
net.ipv4.tcp_fin_timeout | 控制连接进入FIN_WAIT_2后的等待时间 | 30 |
net.ipv4.tcp_keepalive_time | 空闲多久开始发送 keepalive 探测 | 600 |
这里要特别提醒一个坑：老内核里的tcp_tw_recycle不能开，它在 NAT 环境下会导致连接被意外重置，问题排查起来非常头疼。新内核已经把它移除，如果你看到老文章推荐开启这个参数，直接忽略即可。
另外，百万级长连接场景要注意ip_local_port_range。客户端主动连接一个目标端口时，本地端口范围有限，默认通常是32768 60999，也就是两万八千多个端口。如果服务器作为客户端主动向外发起大量连接，很快会端口耗尽。当然，真正百万级并发的服务通常是被连接方，这个参数要到压测客户端身上去调整。
4.4 从单 Reactor 到主从多线程扩展
单 Reactor 单线程模型最大的瓶颈是 CPU 单核上限。一个线程既要 accept，又要读数据，还要写数据，任何一步处理慢了都会拖累所有连接。到了百万级连接，业务再轻也不能只靠一个线程去扛。
主流做法是主从多线程模型，也就是常说的 Main Reactor 加 Sub Reactor：
- Main Reactor 只负责监听新连接，accept 之后把 fd 分发给某个 Sub Reactor。
- 每个 Sub Reactor 有自己独立的 epoll 实例和线程，负责已连接的 fd 上的 IO 事件。
- 业务处理通常再丢给独立的线程池，避免 IO 线程阻塞在计算上。
fd 分配策略尽量固定，比如按连接 id 取模，保证同一个连接总是被同一个 Sub Reactor 线程处理。这样就不容易出现多个线程同时操作一个 fd 的并发问题。另一个思路是利用SO_REUSEPORT让内核把新连接按照哈希自动分散到多个监听 socket 上，每个监听 socket 绑定一个线程，内核层面直接做负载均衡。这个方案的好处是 accept 本身也能并行，坏处是线程和 fd 的绑定关系变弱，连接迁移和统计会更麻烦。
5. 百万级并发下的典型问题和排查记录
5.1 惊群效应：多线程 worker 一起被唤醒
如果你在多个线程里同时对同一个监听 fd 调用epoll_wait，一旦有新连接到达，内核会把这些线程全部唤醒。最终只有一个线程能成功 accept，其他线程白白跑一圈，又回去继续等，这个现象就是惊群。
我排查过这类问题，症状是压测时 CPU 空转很高，但实际处理的新连接数没上去。解决思路有两个：
- 使用
EPOLLEXCLUSIVE标志，它告诉内核同 fd 上只唤醒一个等待线程。 - 使用
SO_REUSEPORT，为每个进程或线程单独创建监听 fd，让内核在 accept 之前就做好分发。
需要注意的是，EPOLLEXCLUSIVE不能和EPOLLONESHOT一起使用，这两个特性组合起来的语义存在限制。而且EPOLLEXCLUSIVE对旧内核支持不好，生产环境先确认内核版本。
5.2 边缘触发与水平触发：怎么选才不丢数据
epoll 的默认行为是水平触发，也就是EPOLLET没设置。水平触发下，只要 fd 上还有未处理的数据，每次epoll_wait都会返回它。这很容易理解，但代价是重复唤醒。边缘触发只在事件状态变化时报一次，效率高，但对程序要求很严格。
选型建议很简单：追求稳定和快速开发，用水平触发；追求极致性能和可预测的唤醒次数，用边缘触发。我在百万连接压测里遇到过边缘触发丢消息的经典案例：某次循环读没读到EAGAIN就退出，然后业务代码又没重新注册事件，之后这个 fd 就再也没被唤醒过。排查到最后发现read明明返回了 0，却被当成了普通情况处理。边缘触发下别自作聪明，老老实实非阻塞加循环读，读到EAGAIN才算完。
5.3 EPOLLONESHOT 与多线程安全
多线程处理同一个 fd 时，没法保证只有一个线程在读这个 socket，两个线程同时读同一个 fd 可能导致数据错乱。EPOLLONESHOT可以保证一个 fd 事件触发之后，不再继续触发，直到你重新注册它。
这非常有用，但记住一个原则：事件处理完之后必须重新调用epoll_ctl修改事件，把这个 fd 重新加回来。如果忘记了，对应的连接会变成“沉默”：再也不会有任何事件上报。我遇到过线上连接越积越多但不读写数据，最后发现就是开发忘记重新注册。
如果你采用主从 Reactor 并且每个连接固定归属一个线程，其实不太需要EPOLLONESHOT。反而是在任务队列加线程池的模式下，业务线程和 IO 线程可能同时碰到 fd，这时EPOLLONESHOT是必要的保护。
5.4 不要在事件循环里干重活：任务队列的边界
事件循环处理一个事件越慢，整个服务吞吐越低。如果handle_read里做了耗时的数据库查询，那么同一线程管理的所有连接都会跟着等待。之前说过咖啡师例子，这就相当于一位咖啡师跑去后厨开始做蛋糕，其他客人的点单全被晾在一边。
正确做法是：读数据、解析数据包，然后投递到线程池，由业务线程执行真正的逻辑，结果再通过任务队列返回给 IO 线程，由 IO 线程继续写 socket。任务队列也要小心，不能无界。如果消费速度跟不上生产速度，队列会越堆越长，内存被吃光，最终 OOM。我习惯给任务队列设置上限，满了之后直接拒绝新任务或者让调用方等待，也就是最常见的背压策略。
6. 压测路上的一些实话和技巧
6.1 从十万连接压到百万连接，环境差异在哪
把服务从十万连接提到百万连接，差距往往不是业务代码，而是整个环境。首先要确认网络中断有没有把 CPU 打满，多队列网卡要打开接收队列调优，让中断分散到多个 CPU 核心。不然出现单核软中断跑满，其余核心闲得发慌，那就是典型的网卡队列配置问题。
其次是内核参数，file-max、somaxconn、tcp_rmem、tcp_wmem这些都要提前调整。别等压测到一半才看日志，连接数还没到十万就先报Too many open files，这种错误很低级，但确实很常见。
最后是内存监控。百万连接下slab内存和 socket 缓冲增长是持续的，不能只看进程 RSS，还要观察系统级内存占用。比如用cat /proc/meminfo看看Slab字段有没有异常增长，如果长期只涨不降，很可能有 fd 泄漏或者连接没有正确回收。
6.2 客户端也要注意：别让压测工具成为瓶颈
压测百万连接时，客户端往往是更容易崩溃的那一端。一台客户端机器要发起百万个连接，它自己也要打开百万个 fd，本地可用端口范围却是有限的。默认的ip_local_port_range只有两万多个端口，单一客户端即使是公网 IP，也根本撑不起百万连接。
解决办法无非三条：多台压测机分摊连接；客户端绑定多个本地 IP；服务端监听多个端口或让客户端连接不同端口。不要只盯着服务端调优，压测拓扑不合理，数据根本没参考价值。我自己测试时习惯把客户端 fd 上限也调到和服务端一个级别，然后单机只连 20~30 万，多台机器配合，才能接近百万。
6.3 我的体会：模型只是起点，业务决定终点
我曾经把一个内部服务从“每连接一线程”改成 Reactor，连接数确实上去了，但吞吐提升没有想象中那么大。后来发现瓶颈不在网络模型，而在业务代码里的锁竞争和序列化开销。网络模型解决了“连接能不能扛住”，业务模型解决的是“扛住之后能干多少活”。很多服务压测成绩漂亮，一上真实业务就崩，基本都是业务线程池、队列、锁的设计出了问题。
几个建议直接送给大家：
- 心跳频率不要太高，很多应用把心跳设置在 30 秒甚至 10 秒一次，百万连接下每秒会产生数万个心跳事件，累积起来非常可观。
- 尽量合并小包发送，把多个消息拼接成一个 TCP 报文，既减少中断次数，也减少系统调用次数。
- 给系统做连接数上限保护，超过阈值时主动拒绝新连接，而不是硬撑到内存耗尽。
- 使用连接状态机管理 fd：新建、已连接、认证中、业务中、关闭中，每个状态对应不同的事件注册方式，不容易出现重复关闭或者事件丢失。
Reactor 模型是你走向百万级并发的一道门，推开门之后还有无数细节等着打磨。每个环境、每个业务都不完全一样，但核心思路是相通的：把等待交给内核，把事件分发给正确的人，把耗时任务请出主循环。你先把这个骨架搭对，再去填参数和业务逻辑，单机百万连接就没有想象中那么遥远。
