worker_processes通过多进程竞争机制实现隐式负载分担，不主动调度流量；其数量应匹配CPU逻辑核心数（推荐auto），过多导致上下文切换开销，过少造成资源闲置，并需配合worker_cpu_affinity、worker_rlimit_nofile、multi_accept等参数协同优化。
worker_processes 本身不直接“分配”流量，而是通过 Nginx 的多进程竞争机制与内核协作，让多个工作进程在高并发下高效、公平地争抢新连接，从而实现隐式负载分担。
worker_processes 如何参与流量承接
它不是调度器，也不做轮询或哈希分发；它的作用是提供并行处理单元。当客户端发起 TCP 连接请求时：
- 所有 worker 进程都监听同一个端口（如 80/443），由内核的 listen socket 队列统一接收
- Nginx 启用 accept_mutex（默认开启）防止“惊群效应”，即同一时刻只允许一个 worker 调用 accept() 获取新连接
- 获得连接的 worker 独立完成后续全部处理：读请求、转发、响应、关闭——全程不跨进程
- 下一个连接到来时，由内核重新唤醒其他空闲 worker 参与竞争，形成动态均衡
为什么数量要匹配 CPU 核心数
过多或过少都会破坏高并发下的吞吐效率：
- 设为 1：所有连接串行排队，单核打满后其余 CPU 闲置，QPS 上限低
- 设得远超核心数（如 16 核配 32 个 worker）：进程频繁切换，CPU 时间大量消耗在上下文切换和锁竞争上，实测 QPS 反而下降 5%～15%
- 设为 auto 或等于逻辑核心数：每个 worker 大概率独占一个 CPU 核运行，缓存局部性好，响应延迟更稳
高并发下需配套的关键动作
仅调 worker_processes 不足以释放性能，必须同步优化底层协同机制：
- 启用 worker_cpu_affinity：把每个 worker 绑定到固定 CPU 核（如 4 核写成
0001 0010 0100 1000），减少跨核缓存失效 - 调高 worker_rlimit_nofile 和系统 ulimit -n：确保每个 worker 能打开足够文件描述符（建议 ≥65535）
- events 块中开启 multi_accept on：让单次唤醒尽可能多地 accept 连接，降低事件循环开销
- 配合 worker_connections 设置合理值（如 10240），总并发能力 = worker_processes × worker_connections
特殊场景的微调逻辑
不是所有高并发都适合“核数=进程数”：
- I/O 密集型业务（如静态文件服务、反向代理）：可略高于核心数（如 ×1.2～1.5），利用等待 I/O 时的 CPU 空闲周期
- CPU 密集型业务（如 TLS 握手、正则重写）：严格限制 ≤ 核心数，避免调度抖动
-
容器化部署：以容器实际分配的 vCPU 数为准（
nproc输出值），而非宿主机核数 - 混合部署服务器：若同机运行数据库等重负载服务，worker_processes 应预留 1～2 核给其他进程
