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 同时管理客户端连接和上游连接，双向异步
