worker_processes 应设为物理核心数，推荐使用auto；需配合worker_cpu_affinity绑定核心、worker_rlimit_nofile调优及multi_accept on等配置，才能实现高并发下低延迟与高资源利用率。
nginx 的并发能力不靠线程堆叠，而靠 Master 与 Worker 的明确分工和低干扰协作。worker_processes 参数不是随便设的数字，它直接决定 Worker 进程数量，进而影响 CPU 利用效率、连接争抢行为和故障隔离粒度。
worker_processes 怎么设才合理
这个指令控制启动几个 Worker 进程，常见取值有三种：
-
具体数字：如
worker_processes 4;，适合固定资源环境，但需手动匹配物理 CPU 核心数（非超线程逻辑核） -
auto：推荐生产环境使用，Nginx 启动时自动读取
/proc/cpuinfo中的cpu cores值，设为物理核心总数，避免跨核调度抖动 - 1：仅用于调试或单核嵌入式场景；此时退化为单进程模型，Master 和 Worker 合并，失去多核并行和进程级容错能力
注意：设得过多（比如远超 CPU 核心数），会导致 Worker 间频繁争抢 accept 锁、上下文切换增多，反而降低吞吐；设得太少，则无法压满多核，浪费资源。
Master 不干活，但管得严
Master 进程以 root 权限启动，但全程不碰网络请求。它的全部职责围绕“稳定”展开：
- 解析并校验 nginx.conf，失败则直接退出，不拉 Worker
- 创建监听 socket（如 0.0.0.0:80），并将其设为
SO_REUSEPORT或交由内核共享给所有 Worker - 按 worker_processes 数量 fork 出对应 Worker 子进程，并持续 waitpid 监控其状态
- 收到信号（如 SIGHUP、SIGUSR2）后，执行重载配置、平滑升级、切日志等动作，再通知 Worker 配合
Master 大部分时间在 sigsuspend() 中挂起，只响应信号唤醒，内存占用通常不到 2MB，CPU 几乎为零。
Worker 干活不通信，靠内核和锁协同
每个 Worker 是独立进程，运行在非 root 用户下（如 www-data），拥有自己的事件循环和内存空间。它们共用监听套接字，但不共享连接、请求或变量状态。协作靠三样东西：
-
accept_mutex：默认开启。新连接到达时，内核通知所有 Worker，但只有拿到互斥锁的那个 Worker 才调用
accept()；其余 Worker 继续等待下一轮事件，避免“惊群”消耗 CPU -
共享内存（shared memory）：用于跨 Worker 统计数据，如
limit_conn_zone、ssl_session_cache、upstream 状态，Master 可读取做决策，Worker 间无需直连通信 - 信号驱动而非主动推送：Master 不向 Worker 发送命令，而是发 SIGUSR1（重开日志）、SIGQUIT（优雅退出）等标准信号；Worker 在事件循环空闲时自行检查并响应，解耦且可控
关键配置要配套生效
只调 worker_processes 不够，还需联动其他指令才能让多进程真正高效起来：
-
worker_cpu_affinity auto;：自动将每个 Worker 绑定到独立物理核心，减少缓存失效和迁移开销 -
worker_rlimit_nofile 65536;：提升单个 Worker 可打开文件描述符上限，否则即使配置了worker_connections 10240，也受系统限制卡住 -
multi_accept on;：让 Worker 在一次 epoll_wait 返回后，尽可能多地 accept 新连接，提升瞬时接入能力 -
use epoll;（Linux 下可省略）：显式指定高性能 IO 多路复用机制，避免 fallback 到低效 select/poll
这些配置共同作用，使一个 4 核机器上 4 个 Worker 能稳定支撑数万并发连接，同时保持低延迟和高资源利用率。
