Nginx高并发能力源于Master-Worker多进程架构：Master仅负责配置加载、Worker管理与信号处理，不参与请求；Worker进程彼此独立、单线程+异步非阻塞事件循环，通过epoll/kqueue高效处理连接；结合CPU亲和性、accept_mutex及原子操作实现无锁协作与资源精准绑定。
Nginx 多进程架构能扛住高并发，关键不在“多”，而在“怎么多”——它用极简的分工、无锁的协作和精准的资源绑定，把每个 CPU 核心的能力榨干，同时避开传统多线程的锁竞争与上下文切换开销。
Master-Worker 职责彻底分离
Master 进程只做三件事：读配置、拉起 Worker、响应信号（比如 reload 或 stop）。它不碰网络、不处理请求、几乎不消耗 CPU。所有真实请求都由 Worker 进程承担，彼此完全独立，内存、文件描述符、连接状态互不共享。一个 Worker 崩了，Master 立刻拉起新的，服务不受影响。
- Master 不参与请求处理，避免成为性能瓶颈或单点故障
- Worker 之间无共享状态，天然规避锁机制
- 配置热重载时，Master 启动新 Worker，等旧 Worker 处理完现有连接后平滑退出
单 Worker = 单线程 + 异步非阻塞事件循环
每个 Worker 进程内部是单线程的，但它靠 epoll（Linux）或 kqueue（BSD）监听成千上万个连接，用状态机驱动整个请求生命周期：接收、解析、转发、响应，全程不阻塞。一次系统调用可批量获取多个就绪事件，避免轮询浪费 CPU。
- 不用为每个连接创建线程或进程，内存占用极低（通常每个连接仅需几 KB）
- 事件就绪才处理，CPU 时间几乎全用于业务逻辑，而非等待 I/O
- 支持 sendfile 零拷贝、TCP_FASTOPEN 等内核优化，进一步减少数据搬运
CPU 亲和性与连接负载均衡
默认情况下，多个 Worker 进程会争抢同一个监听套接字，容易出现“惊群效应”。Nginx 提供两种缓解机制：
- accept_mutex on：Worker 通过原子锁轮流获取新连接，避免大量进程被唤醒却无事可做
- worker_cpu_affinity：显式将每个 Worker 绑定到特定 CPU 核心，减少缓存失效和上下文切换
- 推荐配置 worker_processes auto，让 Nginx 自动匹配 CPU 核心数，再配合 affinity 实现一一对应
共享资源通过无锁原语协作
Worker 之间虽不共享请求上下文，但需要协同管理一些全局资源，比如共享内存中的限流计数器、缓存元数据、SSL 会话复用信息。Nginx 使用 ngx_atomic_t 类型和汇编级原子操作（如 CAS），在不加锁的前提下完成计数、标志更新等高频操作。
- open_file_cache、limit_req、stub_status 等功能依赖这套机制
- 避免了传统锁带来的等待、调度和缓存行颠簸（false sharing）问题
- 即使在万级 QPS 下，共享统计类操作仍保持亚毫秒级延迟
