Nginx多进程架构核心在于Master-Worker分工、CPU绑定、内核协同与资源隔离；Master仅管理配置与进程，Worker独占CPU核心、独立事件循环，通过reuseport和系统参数调优实现高效并发。
Nginx 的多进程架构不是简单地“开多个进程”，而是通过 Master-Worker 分工、CPU 绑定、内核协同和资源隔离，把 CPU、内存、文件描述符、网络连接这几类关键资源真正拧成一股合力。核心不在数量，而在整合逻辑。
Master 与 Worker 各司其职，避免资源混用
Master 进程不处理请求，只做三件事：读取并校验配置、启动/监控 Worker、响应信号（如 HUP 重载、USR2 平滑升级）。它不占 CPU 时间片，也不持有客户端连接或缓冲区。所有计算、IO、内存分配都由 Worker 承担——这种严格分离，让资源调度边界清晰，不会因管理逻辑干扰请求处理路径。
- Worker 进程彼此完全独立，无共享内存（除少数显式配置的共享区，如 limit_req zone）
- 每个 Worker 拥有专属的事件循环、连接池、内存池和定时器队列
- 当某个 Worker 因异常退出，Master 只需拉起一个新进程，不影响其他 Worker 正常服务
Worker 数量与 CPU 核心精准对齐
设 worker_processes auto 是最稳妥的做法。Nginx 启动时会读取系统实际可用的物理 CPU 核心数（非超线程数），并创建对应数量的 Worker。这样每个 Worker 都能独占一个核心，避免调度争抢和缓存失效。
- 在 8 核机器上设为 8，比设为 16 更高效；后者反而增加上下文切换开销
- 容器环境中要以分配到的 vCPU 数为准，而非宿主机总核数
- 配合 worker_cpu_affinity auto，Nginx 自动完成 1:1 核心绑定，无需手写二进制掩码
连接分发靠内核，不靠 Nginx 主动调度
多个 Worker 监听同一端口，但连接如何落到具体进程上，并不由 Nginx 内部算法决定，而是依赖操作系统协作：
- reuseport on（推荐启用）：每个 Worker 创建独立 socket，内核按四元组哈希直接分发新连接，零争抢、低延迟、负载更均衡
- accept_mutex on（默认）：作为 fallback，在旧内核或未启用 reuseport 时，防止多个 Worker 同时被唤醒抢 accept（惊群效应）
- 两者不互斥，现代部署建议 reuseport + accept_mutex off，效果更优
资源限制与系统参数联动配置
Worker 进程再多，若系统层面卡住，照样无法发挥效能。必须同步打通三道关卡：
-
文件描述符：设置 worker_rlimit_nofile ≥ worker_processes × worker_connections，并在
/etc/security/limits.conf中为 nginx 用户提升 soft/hard nofile 限制 -
连接队列：调大
net.core.somaxconn（如设为 65535），避免 listen 队列溢出丢连接 -
TIME_WAIT 复用：开启
net.ipv4.tcp_tw_reuse = 1，加快端口回收，支撑高并发短连接场景
不复杂但容易忽略。
