Nginx的worker_processes本身不直接实现负载均衡，而是通过操作系统调度与Nginx事件分发协同完成进程级负载均衡；需配合accept_mutex off、multi_accept on、worker_cpu_affinity及合理设置worker_connections等参数才能实现真正均摊流量。
Nginx 的 worker_processes 本身不直接实现负载均衡，它只是启动多个独立的工作进程，真正的“进程级负载均衡”依赖于操作系统调度 + Nginx 内部事件分发机制协同完成。关键在于：让每个 worker 进程尽可能均匀承接连接请求，避免空转或争抢，从而压榨多核 CPU 的并行能力。
worker_processes 是负载均衡的底层载体，不是调度算法
- 它定义了 Nginx 启动多少个独立 worker 进程（每个是单线程、事件驱动）
- 每个 worker 独立监听端口（需开启
multi_accept on）、处理连接、转发请求 - 请求最终落到哪个 worker，由内核的
accept()系统调用行为和 Nginx 的连接分发逻辑共同决定
让多个 worker 真正“均摊流量”的核心条件
关闭 accept 锁（避免串行化）
accept_mutex off;（Nginx ≥ 1.11.3 默认关闭；旧版本必须显式配置）
否则所有 worker 会竞争同一个 listen socket，导致“惊群”或排队等待启用批量接收连接
multi_accept on;
让单个 worker 在一次事件循环中尽可能多地accept()就绪连接，提升吞吐，减少空转绑定物理 CPU 核心，避免缓存失效
配合worker_cpu_affinity auto;（≥ 1.9.10）或手动掩码
确保每个 worker 固定运行在不同物理核上，独占 L1/L2 缓存，减少上下文切换与 TLB miss足够大的连接容量支撑
worker_connections 65535;
单 worker 并发上限要够高，否则即使有 8 个 worker，总连接数卡在8 × 1024 = 8192，大量 worker 闲置
不等于“越多越好”，必须匹配硬件与业务特征
- 物理核心数是安全起点：
worker_processes 4（4 物理核）比auto（可能设为 8 逻辑核）更稳 - TLS 终结密集场景可略超物理核（+1～2），但需
top -1观察%us是否真实提升 - WebSocket 或长连接网关建议设为物理核的 1/2～3/4，避免内存与 fd 耗尽
- 容器环境必须按 cgroup 限额设值：
cat /sys/fs/cgroup/cpu/cpu.cfs_quota_us÷cpu.cfs_period_us得实际可用核数
验证是否真“均衡”，别只看配置写了没
-
ps -eo pid,comm,psr | grep nginx：确认每个 worker 运行在预期 CPU 上 -
top -1：观察各 CPU 核%us是否接近（如 4 核都在 60%～85%，而非 2 核 95% + 2 核 15%） -
numastat -p $(pgrep nginx | head -1)：NUMA 架构下检查numa_miss是否持续升高
本质上，worker_processes 是把负载“分片”的基础，而均衡效果取决于它与 worker_cpu_affinity、accept_mutex、multi_accept、worker_connections 的协同。单配一个参数，起不到负载均衡作用。
