reuseport 是 Linux 3.9+ 的机制，通过各 worker 独立创建并设置 SO_REUSEPORT 后 bind/listen，由内核哈希分发连接以避免惊群；须注意设置时机、UID 一致、动态扩缩容风险及 EPOLLEXCLUSIVE 配合。
reuseport 是 Linux 内核自 3.9 版本起引入的底层机制，它从根源上规避了传统多进程监听同一 socket 所引发的惊群效应。关键不在于“怎么开开关”，而在于理解它如何重构连接分发路径——让每个 worker 进程拥有真正独立的 listen socket 实例，而非共享一个 fd。
必须在 bind 前设置 SO_REUSEPORT
这是最易出错的环节。如果先调用 bind()，再 setsockopt(SO_REUSEPORT)，内核会直接拒绝绑定，报错 Address already in use。正确顺序是：
- 创建 socket（AF_INET/AF_INET6）
- 立即调用 setsockopt(fd, SOL_SOCKET, SO_REUSEPORT, &on, sizeof(on))
- 再执行 bind() 和 listen()
注意：所有参与复用的进程都必须对各自 socket 设置该选项，且必须由同一用户 UID 启动，否则内核拒绝复用。
每个 worker 独立完成 socket 生命周期
不能由父进程创建 listen socket 后 fork，否则子进程共享同一 socket 结构体和等待队列，惊群照旧。正确做法是：
- master 进程不创建、不 bind、不 listen 任何网络 socket
- 每个 worker 进程 fork 后，自行调用 socket() → setsockopt(SO_REUSEPORT) → bind() → listen()
- 各 worker 的 listen fd 完全独立，内核为它们分别维护 accept 队列
此时新连接到达时，内核根据四元组（源IP、源端口、目的IP、目的端口）哈希，只将连接分发给其中一个 worker 的队列，并仅唤醒该进程 accept，其余进程完全无感知。
理解其负载均衡边界与局限
reuseport 的哈希分发不是一致性哈希，因此存在两个典型场景需警惕：
- 动态扩缩容时连接失败：新增或下线 worker 进程，会导致哈希桶重分布；若客户端正处于三次握手阶段（SYN 已发、ACK 未达），该 ACK 可能被路由到错误进程，触发 RST，连接建立失败
- 单客户端长连接倾斜：同一客户端 IP+端口始终哈希到同一 worker，无法实现连接级打散；如需更细粒度均衡，需结合客户端 IP 轮询或前置 LVS
生产中建议配合连接数监控，避免个别 worker 因哈希集中而过载。
搭配 EPOLLEXCLUSIVE 进一步加固 epoll 层
即使启用了 reuseport，若 worker 内部使用 epoll LT 模式监听多个 fd（包括 listen fd + client fd），仍可能因事件就绪广播导致轻微唤醒竞争。Linux 4.5+ 提供 EPOLLEXCLUSIVE 选项可彻底解决：
- 对 listen fd 调用 epoll_ctl(EPOLL_CTL_ADD) 时传入 EPOLLEXCLUSIVE 标志
- 内核保证：当该 fd 就绪时，只唤醒 epoll_wait() 队列中第一个等待者
- 适用于 reuseport + 多 worker + epoll 的完整组合，消除最后一环唤醒冗余
该选项需 worker 进程在 epoll_ctl 前显式设置，Nginx 1.11.3+ 默认启用，自研服务需手动适配。
