Nginx 中多进程架构实现资源高效整合

Nginx多进程架构核心在于Master-Worker分工、CPU绑定、内核协同与资源隔离；Master仅管理配置与进程，Worker独占CPU核心、独立事件循环，通过reuseport和系统参数调优实现高效并发。

Nginx 的多进程架构不是简单地“开多个进程”，而是通过 Master-Worker 分工、CPU 绑定、内核协同和资源隔离，把 CPU、内存、文件描述符、网络连接这几类关键资源真正拧成一股合力。核心不在数量，而在整合逻辑。

Master 与 Worker 各司其职，避免资源混用

Master 进程不处理请求，只做三件事：读取并校验配置、启动/监控 Worker、响应信号（如 HUP 重载、USR2 平滑升级）。它不占 CPU 时间片，也不持有客户端连接或缓冲区。所有计算、IO、内存分配都由 Worker 承担——这种严格分离，让资源调度边界清晰，不会因管理逻辑干扰请求处理路径。

1. Worker 进程彼此完全独立，无共享内存（除少数显式配置的共享区，如 limit_req zone）
2. 每个 Worker 拥有专属的事件循环、连接池、内存池和定时器队列
3. 当某个 Worker 因异常退出，Master 只需拉起一个新进程，不影响其他 Worker 正常服务

Worker 数量与 CPU 核心精准对齐

设 worker_processes auto 是最稳妥的做法。Nginx 启动时会读取系统实际可用的物理 CPU 核心数（非超线程数），并创建对应数量的 Worker。这样每个 Worker 都能独占一个核心，避免调度争抢和缓存失效。

1. 在 8 核机器上设为 8，比设为 16 更高效；后者反而增加上下文切换开销
2. 容器环境中要以分配到的 vCPU 数为准，而非宿主机总核数
3. 配合 worker_cpu_affinity auto，Nginx 自动完成 1:1 核心绑定，无需手写二进制掩码

连接分发靠内核，不靠 Nginx 主动调度

多个 Worker 监听同一端口，但连接如何落到具体进程上，并不由 Nginx 内部算法决定，而是依赖操作系统协作：

1. reuseport on（推荐启用）：每个 Worker 创建独立 socket，内核按四元组哈希直接分发新连接，零争抢、低延迟、负载更均衡
2. accept_mutex on（默认）：作为 fallback，在旧内核或未启用 reuseport 时，防止多个 Worker 同时被唤醒抢 accept（惊群效应）
3. 两者不互斥，现代部署建议 reuseport + accept_mutex off，效果更优

资源限制与系统参数联动配置

Worker 进程再多，若系统层面卡住，照样无法发挥效能。必须同步打通三道关卡：

1. 文件描述符：设置 worker_rlimit_nofile ≥ worker_processes × worker_connections，并在 /etc/security/limits.conf 中为 nginx 用户提升 soft/hard nofile 限制
2. 连接队列：调大 net.core.somaxconn（如设为 65535），避免 listen 队列溢出丢连接
3. TIME_WAIT 复用：开启 net.ipv4.tcp_tw_reuse = 1，加快端口回收，支撑高并发短连接场景

不复杂但容易忽略。