nginx多进程架构通过职责分离、资源独占与事件驱动协同提升并发：主进程仅管理配置与worker生命周期，不参与i/o；各worker为独立单线程事件循环，无共享状态、无锁竞争，依托epoll等i/o多路复用高效处理万级连接。
Nginx 的多进程架构不是靠“堆进程”来提升并发，而是通过职责分离、资源独占和事件驱动三者协同，让每个 Worker 进程在不阻塞的前提下，高效复用系统资源处理成千上万连接。
Master-Worker 职责严格分离
Master 进程只做管理类工作：读取配置、启动/监控 Worker、响应信号（如 HUP 重载、USR2 平滑升级）。它不参与任何网络 I/O 或请求解析。所有实际请求都由 Worker 进程承接——每个 Worker 是独立的、单线程的事件循环实例，彼此不共享内存、不抢锁、不通信，天然避免了多线程模型中的上下文切换与同步开销。
- Master 挂了，整个 Nginx 停止；Worker 挂了一个，Master 会立即拉起新进程，服务不受影响
- Worker 数量通常设为 CPU 核心数（worker_processes auto;），确保每个进程绑定一个物理核心，减少调度抖动
- Worker 之间通过操作系统内核的 accept() “惊群”控制机制（如 accept_mutex on; 默认启用）协调新连接分配，避免多个进程同时唤醒争抢
单 Worker 处理海量连接靠事件驱动
每个 Worker 不是为每个连接开一个线程，而是用一个事件循环（event loop）持续监听所有已建立连接的状态变化。它依赖 epoll（Linux）等高效 I/O 多路复用机制，在一次系统调用中批量获知哪些 socket 可读、可写或出错，然后依次回调对应 handler——比如读请求头、转发给 upstream、写响应体。
- 非阻塞 socket + 事件就绪通知，意味着 Worker 在等待磁盘读或后端响应时，立刻转去处理其他就绪连接，CPU 利用率高
- worker_connections 10240; 表示单个 Worker 最多维护 10240 个并发连接（含空闲 keepalive 连接）
- multi_accept on; 让 Worker 在一次 epoll_wait 返回后，尽可能多地 accept 新连接，降低延迟
CPU 与文件描述符资源精准配给
Worker 进程要真正跑满性能，离不开操作系统层面的配合。Nginx 配置只是指令，底层资源需显式放开。
- worker_cpu_affinity auto; 自动将第 N 个 Worker 绑定到第 N 个 CPU 核心，提升缓存局部性
- worker_rlimit_nofile 65535; 提升单 Worker 可打开文件数上限（Linux 默认常为 1024），否则连接数卡在系统限制
- 必须同步调整系统级 limits.conf（如 nginx 用户的 nofile 和 nproc），否则配置无效
零拷贝与连接生命周期优化补足吞吐
Worker 高效运转还需减少数据搬运和连接重建开销。
- sendfile on; 启用内核态零拷贝，静态文件直接从磁盘 DMA 到网卡，跳过用户态内存拷贝
- tcp_nopush on; tcp_nodelay on; 组合使用：前者攒包发（适合大响应体），后者禁 Nagle 立即发（适合小 API 响应）
- keepalive_timeout 65; 复用 TCP 连接，避免频繁握手；反向代理场景下还要配 upstream keepalive 100; 复用到后端的连接
