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%
