Nginx多进程架构采用少量、固定、CPU绑定的Worker进程配合事件驱动模型实现高并发，Master仅管理配置与进程生命周期，Worker独立处理I/O且故障隔离；worker_processes宜设为8或12（非盲目匹配高核数），需搭配worker_cpu_affinity auto、use epoll和multi_accept on，并同步调优worker_connections与系统ulimit。
Nginx 的多进程架构不是靠“堆进程”来扛并发，而是用**少量、固定、绑定 CPU 的 Worker 进程**，配合事件驱动模型，把每个进程的吞吐压到极致。它不追求进程数量，而追求每个进程处理连接的效率和稳定性。
Master-Worker 分工：稳而不重
Master 进程只做配置加载、进程管理、信号响应等轻量工作，不碰网络 I/O；所有真实请求都由 Worker 进程承接。这种分离让服务重启、重载配置时，正在处理的请求不受影响——Worker 进程持续运行，连接不断，真正实现“热更新”。
Worker 进程彼此独立，无共享内存、无锁竞争，故障隔离性好。一个挂了，其他照常服务，不会雪崩。
Worker 进程数怎么设才合理
盲目设成 CPU 核数或更高，反而会拖慢性能：
- CPU ≥ 16 核时，建议显式设 worker_processes 8 或 12，而非 auto 或全核数；
- 64 核机器启 64 个 Worker，上下文切换和缓存失效开销会明显上升；
- worker_cpu_affinity auto 能自动按 NUMA 节点绑定，减少跨节点访问延迟；
- 搭配 use epoll multi_accept on，让单次事件循环尽可能多地 accept 新连接，降低延迟。
单个 Worker 怎么扛住几万连接
每个 Worker 是单线程、异步非阻塞的，靠事件循环 + epoll 驱动：
- socket 全程 non-blocking：accept、recv、send 都不阻塞，遇到 EAGAIN 就立刻切去处理别的就绪事件；
- 连接结构体（ngx_connection_t）在启动时预分配进连接池，复用不 malloc/free；
- 超时管理用红黑树，高效插入/删除，不用轮询；
- HTTP 解析用 slab 分配器，头部字段指针引用原始 buffer，零拷贝；
- keepalive 复用同一 socket 处理多个请求，省掉三次握手和 TLS 握手开销。
连接数与系统限制必须对齐
worker_connections 不是越大越好，要按业务峰值 ×1.2 设定（比如预期 3 万长连接，设 32768 即可），同时必须同步放开底层限制：
- worker_rlimit_nofile 设为与系统 ulimit 一致（如 65535）；
- /etc/security/limits.conf 中加：* soft nofile 65535；
- 避免配置再优，卡在系统文件描述符上限上。
