worker_processes 是 nginx 多进程架构的核心参数，决定每个 cpu 核心运行一个独立、无锁、事件驱动的 worker 进程，以最大化硬件并发能力；必须配合 worker_cpu_affinity 绑核和 ulimit 调优才能生效。
worker_processes 不是“设多少个进程”的简单问题，而是理解 Nginx 多进程架构起点。它的核心作用是让每个 CPU 核心承载一个独立、无锁、事件驱动的工作进程，从而把硬件并发能力真正转化为服务吞吐能力。
为什么必须是多进程，而不是多线程？
Nginx 放弃多线程，是因为线程间共享内存需加锁，高并发下锁竞争会成为瓶颈；而多进程天然隔离——每个 worker 拥有独立内存空间、文件描述符和事件循环，彼此不抢资源，只靠内核调度公平分发连接。Master 进程只管派生和监控，完全不碰请求，保证了控制面稳定。
- 每个 worker 是单线程 + epoll/kqueue 驱动，避免阻塞，一个进程轻松维持数万连接
- 进程间无共享堆内存，彻底规避锁开销和状态同步复杂度
- 故障隔离强：某个 worker 崩溃（如段错误），不影响其他 worker 继续服务
worker_processes 应该设多少？auto 真的可靠吗？
推荐直接写 worker_processes auto;，但前提是明确它“自动”的依据是什么——Nginx 1.3.8+ 版本读取的是系统 逻辑 CPU 核心数（含超线程），不是物理核，也不是容器虚报的 /proc/cpuinfo。
- 查真实可用核数，用 nproc（最准）或 lscpu | grep "CPU(s):"，而非 cat /proc/cpuinfo
- 在 Kubernetes 中，若 limits.cpu 设为 "2"，必须手动设为 worker_processes 2，否则 auto 会按宿主机核数启动，导致资源争抢或静默降级
- 4 核 8 线程机器通常设 8；但若服务以 CPU 密集型计算为主（如复杂 Lua 过滤），可尝试设为 4，减少上下文切换开销
光设对数量还不够：绑核与资源上限必须同步
不绑定 CPU，多个 worker 可能被调度到同一核心上，造成虚假“多进程”假象；不调高文件描述符限制，再好的进程数也卡在 “Too many open files” 错误里。
- 启用 worker_cpu_affinity auto;（Nginx 1.9.10+），或手动指定掩码（如四核：0001 0010 0100 1000）
- 系统级：为 nginx 用户设置 ulimit -n 65536（临时）或写入 /etc/security/limits.conf
- Nginx 级：在 main 块中配 worker_rlimit_nofile 65536;，并在 events 块中合理设 worker_connections（如 4096）
底层设计哲学：用确定性换高性能
Nginx 的设计拒绝“智能调度”，选择显式、可预测的资源分配：一个核一个进程、一个进程一个事件循环、连接由内核公平分发。这种“笨办法”反而规避了运行时调度不确定性带来的缓存失效、跨 NUMA 访存延迟、锁抖动等问题。
- 不依赖 JIT 或动态线程池，降低运行时复杂度
- 所有配置项均可静态验证，上线前就能估算理论并发上限（worker_processes × worker_connections）
- 性能拐点清晰：进程数 ≤ 逻辑核数时，QPS 基本线性增长；超过后，因上下文切换和缓存失效，实测 QPS 反降 5%～15%
