Nginx 中多进程架构实现高并发请求分发

Nginx高并发依赖主从协作、进程隔离与事件驱动：Master仅监管与监听，Worker通过accept_mutex竞争连接并以epoll/kqueue异步处理，单进程支撑数千连接，无需中心分发。

Nginx 的多进程架构不是靠“分发请求”来实现高并发，而是通过主从协作 + 进程隔离 + 事件驱动协同完成的。Master 进程并不主动分发请求，它只负责监听、创建和监管；真正处理请求的是多个独立运行的 Worker 进程，每个都自主、非阻塞地响应连接。

Master 进程不转发请求，只做调度与守护

Master 进程启动后，会预先创建监听套接字（如 80/443 端口），然后 fork 出多个 Worker 进程。这些 Worker 进程继承了监听 socket，但不会同时争抢新连接——Nginx 用 accept_mutex 机制保证任意时刻只有一个 Worker 尝试 accept 新连接，避免“惊群效应”。因此，请求不是由 Master 分发出去的，而是由各 Worker 在锁保护下竞争获取，本质是“被动争用”，而非中心化分发。

• Master 不参与任何网络 I/O，不读写请求体或响应体
• Worker 异常退出时，Master 自动拉起新进程，维持总数稳定
• 平滑重启（如 reload 配置）时，Master 启动新 Worker，旧 Worker 处理完存量连接后退出

Worker 进程单线程 + 事件循环，一个进程撑起数千连接

每个 Worker 是单线程的，但它不为每个连接创建新线程，而是借助操作系统提供的 epoll（Linux）/kqueue（BSD） 实现 I/O 多路复用：在一个线程内同时监控成千上万个 socket 的读写就绪状态。当某个连接有数据可读、可写或关闭时，内核通知 Worker，它立即响应，处理完一小段逻辑后马上返回事件循环，继续处理下一个就绪事件。

• 没有线程切换开销，CPU 利用率高
• 内存池按请求分配、统一释放，减少 malloc/free 频次
• 连接数上限由 worker_connections 和系统文件描述符限制共同决定

CPU 核心数与 Worker 数量需合理匹配

Worker 进程数量通常设为 CPU 物理核心数（或两倍），目的是让每个 Worker 绑定到一个核心，避免上下文频繁切换。过多 Worker 反而增加调度压力；过少则无法充分利用多核资源。可通过 worker_processes auto; 让 Nginx 自动检测核心数，也可手动指定并配合 worker_cpu_affinity 绑核优化。

• 默认配置中 worker_processes 1 仅适合开发或低负载场景
• 生产环境建议设为 auto 或显式设置为 4、8 等值
• 启用 multi_accept on 可让 Worker 在一次事件循环中 accept 多个新连接，提升吞吐

真正的“高并发”来自连接复用与零阻塞等待

Nginx 的并发能力不取决于进程数量本身，而在于每个 Worker 能否在等待上游响应（如 PHP-FPM、数据库）时不挂起整个线程。它把阻塞操作拆解为“发起 → 注册回调 → 去干别的 → 回调触发再续处理”，全程不阻塞。所以即使只有 4 个 Worker，也能轻松承载数万并发连接——只要内存和文件描述符够用，且上游服务不拖慢整体链路。

• HTTP Keep-Alive 复用 TCP 连接，减少握手开销
• 静态资源直接由 Worker 读取文件响应，无需转发
• 反向代理场景中，Worker 同时管理客户端连接和上游连接，双向异步