操作系统内功 · 第 25 篇｜epoll 惊群与 SO_REUSEPORT：多进程抢连接的三代方案

惊群问题：一扇门，一群人，一把钥匙

第 5 篇讲过 epoll 事件循环，但留了一个多进程场景的坑：nginx 这类 master-worker 架构里，worker 进程们共享同一个监听 socket 的 fd（master 在 fork 前创建，子进程继承，第 24 篇的 VFS 对象模型保证它们指向同一个 socket），每个 worker 都把这个监听 fd 加进自己的 epoll。新连接到来时，内核唤醒所有在 epoll_wait 上睡觉的 worker——但 accept 队列里只有一个连接，一个拿到，其余白醒。醒来本身不便宜：调度器切换、缓存被踩（第 31 篇会算这笔账）、白白消耗的 CPU 与延迟抖动。

这就是惊群（thundering herd）。它的恶劣程度随 worker 数线性放大：32 个 worker 的网关，每个新连接造成 31 次无效唤醒——低并发下表现为 CPU 空转、上下文切换飙升；高并发短连接下（爬虫、健康检查风暴）足以让网关自己成为瓶颈。

第一代方案：应用层互斥锁

最早的正解朴素粗暴：加锁，只让一个进程守在 accept 上。nginx 的经典实现：worker 抢进程间互斥锁（早期是文件锁/共享内存锁），抢到的才把监听 fd 放进 epoll，没抢到的 epoll 里没有监听 fd，自然不会被连接事件唤醒。

# nginx 的相关配置（accept_mutex 默认已改为 on 的历史演进见正文）
events {
    accept_mutex on;          # 老版本默认 off，抢锁接入
    accept_mutex_delay 500ms; # 抢锁失败后的重试间隔
}

缺点同样明显：锁竞争与延迟（抢不到的 worker 在 accept_mutex_delay 后重试）、负载不均（抢锁成功率受调度影响，某些 worker 饿死）、代码复杂度高。但它是「内核能力不足时应用自救」的范例——2010 年代前期所有高性能服务器都走过这条路。

第二代方案：EPOLLEXCLUSIVE 与 WQ_FLAG_EXCLUSIVE

Linux 4.5（2016）把解法下沉进内核：EPOLLEXCLUSIVE 标志（配合 EPOLL_CTL_ADD）把监听 fd 的等待队列标记为「互斥唤醒」——新连接到来时内核只唤醒一个等待者，其余继续睡。底层机制是等待队列的 WQ_FLAG_EXCLUSIVE：排队的进程被串成独占队列，唤醒时从队头取一个。

struct epoll_event ev;
ev.events = EPOLLIN | EPOLLEXCLUSIVE;   // 内核 ≥ 4.5
ev.data.fd = listen_fd;
epoll_ctl(epfd, EPOLL_CTL_ADD, listen_fd, &ev);

代价与限制要心里有数：其一，它解决的是「唤醒风暴」，不解决负载均衡——被唤醒的那个 worker 不一定是最空闲的，内核只管从队头挑；其二，多个 epoll 实例附加同一 fd 时，其他事件类型（如 EPOLLHUP）仍可能广播唤醒；其三，它只对 accept 场景有意义，普通连接 fd 上误用反而引入路径切换开销。

第三代方案：SO_REUSEPORT——每个进程一个独立监听队列

真正的架构级解法是 SO_REUSEPORT（Linux 3.9，2013）：允许多个 socket bind 同一个 IP:port，内核在收包时按四元组哈希把连接分流到不同的监听队列——每个进程/线程有自己的 socket、自己的 accept 队列、自己的 epoll，彼此完全独立。

flowchart TB
    IN[新连接 SYN] --> H["内核四元组哈希分流"]
    H --> Q0[socket 0 队列]
    H --> Q1[socket 1 队列]
    H --> Q2[socket 2 队列]
    H --> Q3[socket 3 队列]
    Q0 --> W0[worker 0 独立 epoll]
    Q1 --> W1[worker 1 独立 epoll]
    Q2 --> W2[worker 2 独立 epoll]
    Q3 --> W3[worker 3 独立 epoll]

三个结构性优势让它成为现代默认：零惊群（连接只到达一个队列，物理上没有共享等待者）；内核级负载均衡（哈希分流天然均匀，还能用 SO_ATTACH_REUSEPORT_EBPF 自定义分流策略做灰度）；滚动重启友好（新进程 bind 上来就开始收流量，老进程 close 后内核把它的队列平滑转移）。代价是哈希的随机性——长连接场景下某个 worker 碰上一批重连接（大客户连接恰好哈希到同一队列）会有不均，但 accept 延迟与扩展性的收益远大于此。

实战要点三条：所有参与 REUSEPORT 的 socket 必须在第一个 bind 之前设置该选项（先后不一致会 EADDRINUSE）；进程崩溃时它队列里未 accept 的连接会丢（内核 4.19+ 的 REUSEPORT 模式改进缓解了部分）；TCP 与 UDP 语义不同——UDP 的 REUSEPORT 是按包分流，QUIC/HTTP3 服务端全靠它做多线程收包。

三代方案对照与选型

选型结论一句话：新架构直接 SO_REUSEPORT；只有需要「全局有序 accept」或内核版本不可升级时才回退到锁方案。Go 的 net/http 服务端在多 goroutine 间共享一个 listener，天然无惊群，但多进程部署（复用端口热升级）依然要走 REUSEPORT——goreuseport 类库或自管 socket 传递。

与本系列其他章节的勾连

fd 在进程间的传递（nginx master 把监听 socket 给 worker）靠的是第 16 篇的 SCM_RIGHTS——VFS 的 file 对象模型让「同一个 socket」可以有任意多个持有者，惊群问题的根源正在于此。唤醒一个进程的调度成本、缓存污染的账，第 31 篇（上下文切换）会精确计算——惊群之所以是问题，本质是「无效唤醒」把这笔账乘了 N-1 倍。SO_ATTACH_REUSEPORT_EBPF 的可编程分流是第 9 篇 eBPF 在数据面的直接应用。下一章转到收包路径的另一半：软中断与 ksoftirqd——连接被 accept 之后，数据包在下半部的旅程。

accept 之后的连接分发：fd 与 worker 的亲和策略

惊群解决的是「谁 accept」，accept 之后的第二级问题是「连接的后续处理放哪个 worker」——这决定了缓存与状态的局部性。三代架构给出三种答案。Nginx 模型：worker accept 后自己处理到底——连接的全部请求都由同一个 worker 服侍，连接级的缓冲与状态天然局部；代价是 worker 间负载不均（长连接恰好扎堆某个 worker），SO_REUSEPORT 的哈希分流让不均可控（哈希是随机的但不共享）。Thread-per-core 模型（Seastar、Envoy 的最新架构）：连接绑定到核，从 accept 到响应的全部处理都不跨核——锁消失、缓存局部性拉满、第 18 章的伪共享设计纪律得到贯彻；代价是跨连接的共享状态需要消息传递（Seastar 的 shard 间通信），编程复杂度高。共享队列模型（传统线程池）：accept 后把连接 fd 扔进队列，工作线程随机领取——负载最均匀，但连接状态无局部性、锁与上下文切换最多，只适合短连接无状态服务。选型的判断轴是连接生命期内的工作量：重（长连接、每连接有大量处理）选亲和（Nginx/thread-per-core），轻（短连接、处理极简）选共享队列。折中方案也存在：两级分发（accept 线程只收连接、按哈希派发到固定核的 worker 队列）兼得负载均衡与亲和，Redis 6 的 IO 线程、Nginx 的 reuseport 各 worker 独立队列都是这个形态。架构评审时问一句「连接跟核怎么绑定」，能把一半的网络性能问题扼杀在设计阶段。

多监听队列的观测与调优：REUSEPORT 的运行时视角

SO_REUSEPORT 部署后的运行时观测有几个专门入口。队列水位：ss -lnt 的 Recv-Q/Send-Q 对每个监听 socket 独立显示——某个队列长期比兄弟队列深，说明哈希倾斜或该 worker 处理慢（accept 后应用层卡顿），这是「负载不均」的直接证据；ss -lnt 配合 -- processes 还能看到哪个进程持有哪个监听。哈希倾斜的解法：内核 4.6+ 的 SO_ATTACH_REUSEPORT_EBPF/CPUMAP 允许自定义分流程序（按源 IP 段、按连接数），云厂商的 L4LB（如 Facebook 的 Katran）用它做一致性哈希。热升级的观测（接运维侧）：新旧进程并存的窗口里，ss -lntp 会显示两个监听者——确认老进程的监听已关闭（新连接全走新进程）而存量连接仍在老进程，drain 完成后老进程退出；conntrack -L 里 TIME_WAIT 的衰减速率是「老流量是否清完」的计时器。一个部署陷阱值得点名：容器环境里 Pod 副本天然是多个进程各自 REUSEPORT 同一端口（hostNetwork 或 CNI 的透明代理场景），滚动发布时新旧 Pod 混跑，新老 Pod 的内核缓冲参数（somaxconn、backlog）不一致会让新 Pod 悄悄少收流量——端口级参数要纳入部署清单的一致性检查。REUSEPORT 是「免费的性能」但不是「免维护的性能」，队列水位与哈希倾斜的巡检应该成为网关的常规体检项。

DNS、 accept 与连接建立的观测闭环

连接建立路径上有两个常与惊群混淆的观测点，值得放进同一条闭环里。第一个是 accept 队列溢出与 SYN 的关系：netstat -s 里 TcpExtListenOverflows 增长而 CPU 空闲，常被误诊为「惊群」或「连接数不够」——真相是应用 accept 得慢（worker 卡在别的活上）或 backlog 参数（listen 的第二参数与 somaxconn 的较小值）太小，与唤醒机制无关；REUSEPORT 的多队列还让排障多一维：总溢出不变但分布到多个队列，单队列溢出的告警阈值要按队列数重算。第二个是 SYN 与 accept 的延迟测量：内核 4.1+ 的 TCP_INFO（tcpi_delivery_rate 等字段）与 ss -ti 的输出能拿到每条连接的建连耗时分解（SYN 重传次数、RTT），把「用户感觉慢」拆成「网络慢」还是「accept 慢」——后者才回到本篇的方案域。闭环的观测配置建议：监听队列水位（ss -lnt 的 Recv-Q 与 Somaxconn 差值）、溢出计数（ListenOverflows 与 ListenDrops）、建连延迟分位数三项进网关的常规监控；REUSEPORT 队列数变更（扩容 worker）后跑一轮压测看队列水位的均匀度。这三项加第 25 篇正文的三个方案，构成「连接建立性能」的完整工程包——诊断有指标、修复有方案、验证有数据。

回到工程：把方案落成一张部署检查单

SO_REUSEPORT 落地时的检查单不长，但每条都对应一次事故。一、所有 bind 同一端口的进程必须同版本内核同参数（somaxconn、backlog、tcp_nodelay 一致），参数漂移会造成静默的流量倾斜——部署清单把端口参数声明为集群级常量。二、进程启动顺序上，选项设置必须先于 bind（SO_REUSEPORT 在第一个 bind 时生效语义），库封装（如 Go 的 net.ListenConfig.Control）要在 Control 回调里设置，别放在 bind 之后。三、滚动发布配 drain：新进程起、老进程关监听不关连接，超时强断要有日志——「连接去哪了」的工单比 drain 的复杂度贵得多。四、监控三件套：各队列 Recv-Q 水位、ListenOverflows 计数、建连延迟分位数，三项任一异常都指向本篇方案的某个环节失效。五、压测验证：扩容 worker 后看队列水位的均匀度与吞吐斜率，斜率不线性说明哈希或亲和出了问题——REUSEPORT 的每一分性能都要用数据验收。

小结

惊群的本质是「共享等待队列上的无效唤醒」：N 个等待者为一个事件全部醒来，N-1 次是浪费。三代方案的演进逻辑清晰：应用层互斥锁（能跑但复杂且不均）、EPOLLEXCLUSIVE（内核互斥唤醒，治标）、SO_REUSEPORT（多监听队列物理分流，治本且附赠负载均衡与热升级）。选型结论是现代架构直接 SO_REUSEPORT，理解锁方案的价值在于读懂存量代码。它连接着 fd 传递（第 16 篇）、唤醒成本（第 31 篇）与 eBPF 分流（第 9 篇），是网络编程从「能跑」到「能扩」的分水岭问题。