Nginx 的 worker_processes 与 upstream weight 完全无关：前者是单机进程调度（匹配 CPU 核心数、绑定亲和性、epoll 事件模型实现请求均衡分担），后者是集群层后端服务器的请求计数比例；所谓“Worker 动态负载权重”并不存在，真正的动态权重需通过 least_conn、least_time 或 Consul/Lua 等外部机制实现。
Nginx 的 worker_processes 本身不参与负载均衡的权重分配，它和 upstream 中的 weight 完全无关。这是个常见误解。
worker_processes 是 Nginx 主进程 fork 出的工作进程数量，负责接收、分发、处理客户端连接（包括反向代理请求），属于单机资源调度层；而 weight 是在 upstream 块中为后端服务器设置的，属于集群流量分发层。两者不在同一层级，也不能“动态调整权重”。
所以准确来说：
Nginx 没有“Worker Process 动态负载权重”这回事。
但你可能实际想问的是以下两类问题之一，我们分别说清楚：
Worker 进程如何高效协同处理请求（非权重，是负载分担）
-
worker_processes auto;自动匹配 CPU 核心数，避免多进程争抢 - 配合
worker_cpu_affinity绑定每个 worker 到独立 CPU 核，减少上下文切换 - 开启
accept_mutex on;（默认开启）让 worker 轮流抢 accept 锁，避免惊群 - 使用
epoll（Linux）或kqueue（BSD）事件模型，单 worker 高效处理上万并发连接
这些不是“权重”，而是通过内核机制和进程协作实现请求的自然均衡分担。
后端服务器的权重怎么动态调整（这才是真正的“动态负载权重”）
这才是业务中真正需要的“动态”：
- 静态
weight只是初始比例，无法响应后端真实负载变化 - 真正可行的动态方式有：
- 启用
least_conn：优先转发给当前活跃连接最少的后端，天然适配长连接/慢接口场景 - 启用
least_time（商业版 NGINX Plus 或开源版需编译模块）：基于响应时间加权，自动倾向更快节点 - 结合外部系统实现动态权重：
- Consul + nginx-upsync-module：从 Consul KV 实时拉取
weight、max_fails等参数，热更新 upstream - Prometheus + 自定义脚本：监控各后端 CPU/RT/错误率，自动调用 API 更新 Consul 中的 weight 值
- OpenResty + Lua：在
init_worker_by_lua_block中定时拉取指标，用balancer_by_lua_block实现自定义调度逻辑
- Consul + nginx-upsync-module：从 Consul KV 实时拉取
- 启用
权重设置的关键提醒
-
weight不是算力权重，只是请求计数比例（例如 weight=4 和 weight=1 → 每 5 个请求分 4 个给 A、1 个给 B） - 必须搭配
max_fails和fail_timeout，否则故障节点仍持续收请求 - 单靠 weight 无法解决“A 机器卡死但权重高仍被狂打”的问题，必须叠加健康检查或连接策略
不复杂但容易忽略。
