Nginx的worker_processes是独立并行处理不同连接的进程，不协同处理同一请求；每个worker独占事件循环、全程处理单个请求，通过accept_mutex或SO_REUSEPORT实现内核级连接分发，并借助共享内存与自旋锁协调全局状态。
Nginx 的 worker_processes 并不是“协同”执行同一请求，而是各自独立、并行地处理不同连接——它们之间不共享请求上下文，也不协作完成单个请求，而是通过操作系统和 Nginx 自身机制实现高效、无竞争的负载分发。
每个 worker 进程独占一个事件循环
每个 worker 进程启动后，都运行自己的异步事件循环（基于 epoll/kqueue 等），监听同一个端口（如 80/443）。它们互不通信、不共享连接状态，但都能接收内核分发的新连接。这种设计避免了线程锁、内存同步开销，也杜绝了单点阻塞影响全局。
- 一个 worker 崩溃，只影响它正在处理的连接，master 会立即拉起新 worker 替代
- 所有 worker 使用相同的配置和代码逻辑，但拥有独立的内存空间与文件描述符
- 没有跨 worker 的请求转发或接力；每个 HTTP 请求从 accept 到 close 全程由同一个 worker 完成
操作系统负责初始连接分发
当客户端发起 TCP 握手，Linux 内核根据 SO_REUSEPORT（若启用）或传统 accept 队列机制，将新连接分配给某个正在调用 accept() 的 worker。Nginx 默认开启 accept_mutex on，确保任一时刻只有一个 worker 尝试 accept，避免“惊群”（thundering herd）问题。
- 未启用
accept_mutex时，多个 worker 可能同时被唤醒争抢 accept，造成 CPU 浪费 - 启用后，worker 轮流获得 accept 权限，更公平且降低系统调用开销
- 在较新内核（4.5+）中，配合
SO_REUSEPORT可关闭accept_mutex，由内核直接做哈希分发，吞吐更高
共享资源靠共享内存 + 自旋锁协调
虽然 worker 间不共享请求，但在需要全局状态的场景（如限流、缓存、连接计数、SSL 会话复用），Nginx 使用共享内存段（shared memory zone）供所有 worker 访问。访问时通过自旋锁（spinlock）保证原子性，而非系统级信号量。
- 例如：
limit_req_zone $binary_remote_addr zone=one:10m rate=1r/s;中的zone=one即为共享内存区 - 锁持有时间必须极短；长时间占用会导致其他 worker 空转等待，拖慢整体性能
- 第三方模块若未遵循快速加锁/释放原则，易引发性能下降甚至死锁
配置建议：数量与 CPU 绑定
worker_processes 设置过少会浪费多核能力，过多则增加调度开销和上下文切换。推荐值通常等于 CPU 物理核心数，并可结合 worker_cpu_affinity 绑定到指定核心，提升缓存局部性。
- 示例配置：
worker_processes auto;或worker_processes 4; - 绑定写法：
worker_cpu_affinity 0001 0010 0100 1000;（四核机器上一一对应） - 避免设为远超 CPU 核数（如 64），除非业务有大量 I/O 等待且 CPU 不饱和
