Nginx Worker进程无动态负载调节机制，均衡依赖配置与内核协作；最有效手段是启用reuseport（Linux 3.9+/Nginx 1.9.1+），配合关闭accept_mutex、调优multi_accept和worker_connections，并结合监控定位真实瓶颈。
Nginx 多进程模型中，Worker 进程本身不支持“动态调整工作负载”——它没有运行时权重调节机制，也不在进程间主动调度或转移请求。所谓“动态调负载”，实际是通过配置优化与内核协作，让多个 Worker 在高并发下更均匀地承接连接，避免个别进程长期过载。
用 reuseport 让内核自动分发新连接
这是目前最有效、最轻量的均衡手段，适用于 Linux 3.9+ 和 Nginx 1.9.1+：
- 在 listen 指令后加上 reuseport，例如：
listen 80 reuseport; - 内核会基于源 IP + 端口哈希，把新 TCP 连接直接分发到不同 Worker 的监听队列
- 天然规避“惊群”，无需进程争抢 accept 锁，连接分布更接近随机均匀
- 启用后建议关闭
accept_mutex off;，避免两者冲突
合理控制每个 Worker 的连接处理节奏
防止慢请求或长连接把某个 Worker “钉住”，导致其他 Worker 空闲：
- 开启
multi_accept on;，让每个 Worker 一次尽可能多地从内核队列中取出连接，减少轮转延迟 - 适当调大
worker_connections（如 10240），避免连接排队堆积在少数 Worker 上 - 对 HTTP/2 或 WebSocket 服务，配合设置
keepalive_timeout和keepalive_requests，限制单连接生命周期，释放资源
结合监控识别真实不均原因
负载不均常是表象，背后可能是外部瓶颈而非 Nginx 调度问题：
- 用
ps -eo pid,comm,%cpu,%mem,rss --sort=-%cpu | head -20查看各 Worker CPU 和内存占用是否明显偏离 - 在 access.log 中加入
$pid变量，统计各 Worker 处理请求数，确认是否真不均 - 检查
$upstream_addr字段，判断是 Worker 接收不均，还是 upstream 分发不均（后者需调 upstream 策略） - 留意 SSL 握手、日志刷盘、磁盘 I/O 等阻塞操作，它们会让某个 Worker 暂时卡住
不要误用 weight 去调 Worker 负载
upstream 中的 weight 参数和 worker_processes 完全无关：
- weight 控制的是反向代理时“请求发给哪台后端服务器”，属于集群层流量分发
- worker_processes 是单机进程数，只影响本机并发处理能力，不参与任何跨服务器的权重决策
- 试图通过改 weight 来“平衡 Worker 负载”，既无效，也混淆了架构层级
