Nginx多进程架构以轻量、隔离、可控应对高并发，通过进程级隔离+事件驱动实现稳定高性能；worker崩溃不影响全局，无锁无共享内存，内存可控且易运维；支持CPU亲和绑定、accept_mutex防惊群、sendfile零拷贝等优化。
Nginx 多进程架构的核心价值，在于用轻量、隔离、可控的方式应对高并发网络请求，而非靠堆线程或异步回调来“硬扛”。它不追求单点极致吞吐，而是通过进程级隔离 + 事件驱动内核协同，实现稳定、可预测、易运维的高性能。
进程隔离带来天然稳定性
每个 worker 进程独立运行、无共享内存，崩溃后仅影响当前连接，master 进程会立即拉起新 worker 继续服务。这避免了 Apache 类模型中一个线程卡死拖垮整个进程的问题。尤其在处理慢连接、长 keepalive 或第三方模块异常时，故障边界清晰。
- worker 进程间不通信、不竞争锁，消除了多线程场景下的锁争用与上下文切换开销
- 内存占用可控：每个 worker 默认栈空间远小于线程（Linux 线程栈通常 8MB，worker 进程整体内存常在 20–100MB 区间）
- 便于调试与监控：可通过 kill -USR1 触发单个 worker 日志重载，或用 nginx -t 验证配置而不中断服务
CPU 亲和性提升多核利用率
默认情况下，worker 进程可能被内核随机调度到任意 CPU 核心，导致缓存失效频繁、TLB 刷新增多。启用 worker_cpu_affinity 后，可将每个 worker 绑定到指定核心，显著降低跨核中断和 L3 缓存抖动。
- 配置示例：worker_processes auto; 与 worker_cpu_affinity auto; 可自动匹配物理核心数并绑定
- NUMA 架构下建议配合 numactl 启动，如：numactl --cpunodebind=0 --membind=0 nginx，确保 CPU 与本地内存协同
- 避免设置 worker 数量超过物理核心数（超线程可适度增加，但不宜翻倍）
连接分配机制防止惊群与负载倾斜
多个 worker 同时监听同一端口时，内核可能把所有新连接都派给某个活跃 worker，造成“惊群效应”。Nginx 通过 accept_mutex（默认开启）协调竞争，让 worker 轮流获取 accept 权限，再结合内核 EPOLL 的边缘触发（ET）模式，保障连接均匀分发。
- accept_mutex 本质是进程间互斥锁，由 master 进程协调，避免空转争抢
- 在高并发短连接场景下，可临时关闭该锁（accept_mutex off;），依赖内核 SO_REUSEPORT 支持更细粒度分发（需 Linux 3.9+）
- 连接数上限由 worker_connections × worker_processes 决定，但实际应略高于峰值 QPS × keepalive_timeout，防止空闲连接长期占位
静态资源场景下的协同优化
多进程本身不解决磁盘 IO 瓶颈，但为上层优化提供了稳定执行单元。例如 sendfile 零拷贝、open_file_cache 文件元数据缓存、gzip_static 预压缩等特性，都在每个 worker 内独立生效，互不影响。
- 启用 sendfile on; + tcp_nopush on;，让内核直接 DMA 传输文件，绕过用户态缓冲
- open_file_cache max=10000 inactive=60s; 减少 stat()/open() 系统调用，特别适合大量小文件场景
- 配合 expires 1y; 或 add_header Cache-Control "public, immutable";，把缓存压力卸载到客户端
