reuseport 使每个 worker 独立绑定端口，内核按四元组哈希直接分发新连接至对应监听队列，消除 accept 锁争抢与惊群效应；需 worker_processes 匹配物理核心数、multi_accept on、worker_connections 足够大，并配合系统 ulimit 调优。
Nginx 的 worker_processes 本身不调度请求，它只是启动多个独立进程；真正让新连接落到不同 worker 上的，是 reuseport 这个内核级机制——它绕过 Nginx 层的锁竞争，由操作系统直接分发。
reuseport 如何改变连接分发逻辑
启用 reuseport on; 后，每个 worker 进程会各自调用 bind() 和 listen() 绑定到同一个端口（如 80），内核为每个 worker 分配一个独立的监听 socket 完全队列。当新 TCP 连接到达时，内核按四元组（源 IP + 源端口 + 目标 IP + 目标端口）做哈希，直接将连接放入某个 worker 对应的队列，无需任何进程间协调。
- 没有 accept 锁争抢，消除了“惊群效应”
- 分发更均匀，长期运行下各 worker 接收连接数接近理论均值
- 延迟更低，尤其在高并发短连接场景下优势明显
worker_processes 数量必须合理匹配
reuseport 发挥效果的前提，是 worker 数量与硬件能力对齐：
- 设为物理 CPU 核心数（非超线程数），例如 8 核服务器配
worker_processes 8; - 配合
worker_cpu_affinity auto;可自动绑定核心，减少缓存抖动 - 过多 worker（如 16 个跑在 4 核机器上）会导致上下文切换开销上升，反而降低吞吐
- 过少 worker（如只设 1）则无法利用多核，reuseport 失去意义
需配套的关键配置项
单独开 reuseport 不够，还需激活协同机制：
-
use epoll;（Linux 下默认，但显式声明更稳妥） -
multi_accept on;：让每个 worker 单次事件循环尽可能多地 accept 就绪连接，避免遗漏 -
worker_connections 10240;：足够大的连接上限，支撑高并发，同时影响ngx_accept_disabled的触发阈值 - 系统层面确保
ulimit -n足够大（如 65536），否则 worker 无法打开足够文件描述符
与 upstream 负载均衡的关系
注意：reuseport 解决的是「Nginx 自身接收连接」的分发问题，不是后端服务的负载均衡。它只决定哪个 worker 进程拿到新连接；后续该连接内的所有请求（包括 proxy_pass 到 upstream）均由这个 worker 独立完成。upstream 的算法（如 least_conn、ip_hash）在每个 worker 内部独立运行，不跨进程同步状态，但因连接入口已较均匀，整体流量自然趋于平衡。
