nginx多进程架构通过master-worker职责分离、worker与cpu核心精准绑定、事件驱动异步非阻塞模型及accept_mutex防惊群等机制，实现稳定高效百万并发；worker_processes设为auto为最优实践，实测32核下比固定值性能高15%。
Nginx 的多进程架构不是为“堆数量”而设计，而是通过职责分离、资源隔离与硬件协同，让每个进程稳且高效地跑满 CPU 核心，从而实现稳定高并发。关键不在多，而在“分工明确 + 互不干扰 + 绑定到位”。
Master-Worker 职责严格分离，故障不影响服务
Master 进程只做三件事：读配置、拉 Worker、收信号（如 HUP 重载、TERM 关闭）。它不碰网络、不处理请求，内存和 CPU 占用极低；Worker 进程则完全独立运行，各自持有文件描述符、内存空间和事件循环。一个 Worker 崩了，Master 立刻拉起新进程，已建立的连接不受影响，用户无感知。
- 配置热重载靠 Master 转发信号，无需中断连接
- Worker 异常退出时，Master 记录日志并自动补位
- 所有 Worker 共享同一份配置副本，但运行时互不通信——避免锁竞争
Worker 数量与 CPU 核心精准匹配
worker_processes 设置为 auto 是当前最优实践。Nginx 会自动识别物理核心数，并在 NUMA 架构下优先绑定同节点核心，减少跨节点内存访问延迟。手动设为 32 或 64 反而可能因进程迁移导致缓存失效，实测在 32 核机器上 auto 比固定值性能高约 15%。
- 不建议设为 CPU 核心数的 2 倍——除非 IO 密集型场景且确认有足够上下文切换余量
- 虚拟机或容器环境需注意：/proc/cpuinfo 报告的核心数是否真实可用
- worker_rlimit_nofile 必须同步调高，否则连接数受限于系统默认 1024
CPU 亲和性绑定 + accept_mutex 防惊群
每个 Worker 绑定唯一 CPU 核心（worker_cpu_affinity），彻底消除进程调度开销；同时启用 accept_mutex（默认开启），确保同一时刻仅一个 Worker 尝试 accept 新连接，避免多个进程同时被唤醒争抢 socket（即“惊群效应”）。
- 典型配置：worker_processes auto; worker_cpu_affinity auto;
- 长连接较多时，可配合 use epoll 和 multi_accept on，提升单次事件批量处理能力
- Linux 4.5+ 支持 EPOLLEXCLUSIVE，可替代 accept_mutex，更轻量
事件驱动 + 异步非阻塞，单 Worker 扛万连
每个 Worker 是单线程、事件驱动模型，依赖 epoll（Linux）或 kqueue（BSD）监听成千上万个 socket。它不为每个连接开线程，也不阻塞等待数据，而是轮询就绪事件，顺序处理读写。这意味着一个 Worker 在 4GB 内存下轻松维持 5–10 万并发连接。
- worker_connections 建议设为 10240 或更高，但需与系统 ulimit 匹配
- keepalive_timeout 设为 60–75 秒，平衡复用率与连接堆积风险
- sendfile on + tcp_nopush + tcp_nodelay 组合，优化静态文件传输路径
