Nginx 的 worker_processes 本身不主动负载分摊，而是靠内核 SO_REUSEPORT 和 accept 协作实现连接均匀分发，配合 multi_accept on、worker_cpu_affinity 绑定物理核心及合理设置 worker_connections 与系统 ulimit，才能实现高并发下进程级均衡。
Nginx 的 worker_processes 本身不主动做负载分摊，它只是启动多个独立工作进程；真正让请求在进程间相对均匀分布，靠的是操作系统内核机制和 Nginx 内部事件协作的组合效果。
靠内核与 accept 协作实现连接分发
多个 worker 进程默认监听同一端口（如 80/443），内核负责把新连接分发给某个 worker。关键在于：
- 关闭 accept_mutex（旧版本需显式配置）：Nginx ≥ 1.11.3 默认关闭，避免所有 worker 串行争抢 listen socket，减少排队等待
- 启用 SO_REUSEPORT（Linux 3.9+）：让内核在多个进程间直接分发新连接，比 accept_mutex 更高效、更均衡
- 开启 multi_accept on：单次事件循环尽可能多地 accept 就绪连接，减少空转，提升单个 worker 吞吐
绑定 CPU 核心减少干扰
每个 worker 固定运行在指定物理核心上，能显著提升缓存局部性与响应一致性：
- 用 worker_cpu_affinity auto（≥ 1.9.10）自动绑定，或手动设置掩码（如
worker_cpu_affinity 0001 0010 0100 1000;） - 避免跨核调度导致 L1/L2 缓存失效、TLB miss 增多
- 特别适合高频率代理转发场景（如 API 网关）
数量匹配硬件，避免失衡
worker 进程数不是越多越好，而是要与物理计算资源对齐：
- 推荐设为 物理核心数（非逻辑核数），例如 4 物理核 →
worker_processes 4 - 用
lscpu | grep -E "Core|Socket"确认真实物理核心总数 - TLS 终结密集型可略超物理核（+1～2），但需观察
top -1中 %us 是否真实上升
配合连接容量支撑并发均摊
光有进程数不够，每个 worker 必须能承载足够连接，否则部分进程闲置：
- worker_connections 要设足够大（如 65535），否则总并发上限 = 进程数 × 该值
- 系统级限制也要同步调高：
ulimit -n至少 ≥ worker_processes × worker_connections - 若后端平均需 2000 并发连接 × 10 台服务器，则 Nginx 至少需支持 2 万以上连接
