nginx进程间无主动负载均衡，依赖worker_processes匹配cpu核数、accept_mutex防惊群、reuseport由内核哈希分发连接，实现高效并发分发。
Nginx 本身不提供进程间负载均衡——它没有“让多个 Nginx 进程互相分担请求”的机制。这个说法容易引起误解，需要先厘清概念：
Nginx 的架构是 Master-Worker 模型，其中：
- Master 进程只负责管理（读配置、启停 Worker、热重载等），不处理请求；
- 所有 HTTP/Stream 请求均由多个 独立的 Worker 进程并行处理；
- Worker 进程之间不共享连接、不转发请求、也不协调负载，而是通过操作系统内核的
accept()争抢机制（配合accept_mutex）来实现请求的近似均匀分发。
所以，所谓“Nginx 进程间负载均衡”，实际指的是：如何让多个 Worker 进程高效、公平地承接并发连接。这不是靠 Nginx 主动调度，而是靠合理配置 + 内核协作。
✅ 正确理解与关键配置
1. Worker 进程数量要匹配 CPU 核心数
worker_processes auto; # 推荐：自动设为 CPU 核心数 # 或显式指定，如 worker_processes 4;
- 每个 Worker 是独立进程，绑定到一个 CPU 核心更高效；
- 过多（如远超核心数）会导致上下文切换开销上升；
- 过少（如设为 1）无法充分利用多核，成为性能瓶颈。
2. 启用 accept_mutex（默认开启，建议保留）
events {
accept_mutex on; # 默认值，防止“惊群”（thundering herd）
worker_connections 1024;
}
- 多个 Worker 同时监听同一端口时，
accept_mutex让它们排队获取新连接，避免大量进程被唤醒却只有一个能成功accept； - 这不是“负载均衡算法”，但它是实现 Worker 间请求分发公平性的底层保障。
3. 开启 reuseport（Linux 3.9+，推荐启用）
events {
use epoll;
multi_accept on;
reuseport on; # 关键！由内核在 socket 层做连接分发
}
-
reuseport允许每个 Worker 绑定同一个端口的独立 socket； - 内核根据哈希（源IP+端口+目标IP+端口）把新连接直接分给某个 Worker，彻底绕过
accept_mutex争抢； - 效果更均衡、延迟更低、吞吐更高，是现代高并发部署的推荐实践。
⚠️ 注意：
reuseport需要 Nginx ≥ 1.9.1 且 Linux 内核 ≥ 3.9；CentOS 7 默认内核较老，需确认或升级。
4. 避免 Worker 负载倾斜的常见干扰项
- ❌ 不要手动
kill -USR2只重启部分 Worker（Nginx 不支持）； - ❌ 不要设置
worker_cpu_affinity错误（如绑错核心或遗漏）； - ✅ 推荐搭配：
worker_cpu_affinity auto; # 自动绑定各 Worker 到不同 CPU 核心
❌ 常见误区澄清
| 说法 | 是否正确 | 说明 |
|---|---|---|
| “Nginx 可以配置多个进程轮流处理请求” | 否 | Worker 不轮询，是内核分发或争抢 accept
|
| “用 upstream 把请求转给本机其他 Nginx 进程实现负载” | 不推荐 | 属于反向代理嵌套，增加无谓开销，违背设计初衷 |
“调大 worker_connections 就能提升并发” |
有条件 | 还需系统 ulimit -n、net.core.somaxconn 等配合 |
总结一句话
Nginx 的“进程间负载”本质是：靠合理设置 worker_processes + 启用 reuseport（或依赖 accept_mutex）+ 内核协作，让每个 Worker 自然、高效、低冲突地承接连接。它不是传统意义的“调度式负载均衡”，而是一种轻量、内核友好的并发分发机制。
