nginx worker_processes 是彼此独立、平等竞争的并发处理单元，不共享内存、不通信、不协调；每个 worker 为单线程事件循环，基于 epoll 非阻塞处理全链路请求，靠 accept_mutex 和 cpu 绑定实现高效并行。

Nginx 的 worker_processes 并不是“一起干活”的协作关系，而是彼此独立、平等竞争的并发处理单元。它们不共享内存、不通信、也不协调任务分配，靠 Linux 内核和 Nginx 自身机制实现高效并行。

每个 worker 进程是独立的事件循环

每个 worker 是单线程、非阻塞、基于 epoll（Linux）的事件驱动引擎。它独自监听端口、接收连接、读取请求、转发代理、写回响应——全程不依赖其他 worker。这种设计避免了多线程锁开销和上下文切换干扰。

• 主进程（master）只负责管理：加载配置、启动/重启 worker、平滑升级
• worker 之间无通信，不传递连接，也不分片请求
• 新连接到来时，所有 worker 都可能被内核通知，但通过 accept_mutex（默认开启）确保仅一个 worker 成功 accept，其余自动放弃

并发能力由数量与系统资源共同决定

worker 进程数本身不提升单请求性能，而是扩大并行处理的“车道数”。真正释放并发潜力，需要三者匹配：

linux-sysadmin

Linux系统管理专家，覆盖12大模块：用户权限、SSH、存储、网络、systemd、防火墙、日志监控、备份恢复、TLS证书、Ansible、容器、IaC。提供配置、验证、加固、监控、备份、自动化、故障排查、回滚闭环。关键词：useradd、sudo、sshd_config、chmod、SEL...

下载

• CPU 核心数：设为物理核心数（如 8 核 → worker_processes 8），避免超线程争抢缓存
• 文件描述符上限：每个连接占一个 fd，需同步调高 worker_rlimit_nofile 和系统 ulimit -n
• 单进程连接上限：配合 worker_connections（如 10240），总并发 ≈ 进程数 × 每进程连接数

CPU 绑定让并发更稳定可靠

不绑定时，Linux 调度器可能把同一个 worker 在不同核心间迁移，导致 L1/L2 缓存失效、TLB 刷新增多、SSL 会话复用率下降。启用 worker_cpu_affinity 后：

• 每个 worker 固定运行在专属物理核心上（例如 worker_cpu_affinity auto;）
• 缓存局部性增强，响应延迟更平稳，尤其在高 QPS 或 API 网关场景下效果明显
• 手动配置需确保掩码一一对应，且不重复绑定同一物理核

容器与混合部署需特别注意

在 K8s 或 Docker 环境中，auto 可能误读宿主机核数；共存数据库或 Java 应用时，要预留计算资源：

• 容器内应显式设置，如 worker_processes 2;（按实际分配 vCPU 数）
• 混合部署可减去 1–2 核：worker_processes $(nproc --all)-2;
• 避免盲目翻倍（如 16 核设 32 worker），实测可能因调度压力导致 QPS 下降 5%～15%