加权轮询是静态比例分发机制，不感知后端负载与响应延迟；需配合least_conn、主动健康检查及实测权重设定才能应对大并发。
加权轮询本身不处理“调度延迟”，它只是按预设权重比例分发请求，不感知后端是否繁忙、响应是否变慢。所谓“权重调度延迟”，其实是大并发下权重机制与真实负载脱节导致的流量错配——高权重节点积压请求，低权重节点空闲，用户感知为整体响应变慢。
权重不是实时能力映射，而是静态比例分配
比如配置 server A weight=5; server B weight=1，Nginx 会严格按 5:1 的请求计数分发（如每6个请求中5个去A、1个去B）。但若A节点因数据库慢查已堆积200个待处理请求，Nginx仍会把第5、第11、第17…个请求继续发给它——这不是“调度延迟”，是机制本就不含动态反馈。
- 权重 ≠ 当前可用容量，也不等于P95响应时间倒数
- 它只在连接建立那一刻起作用，不干预请求执行过程
- 短时突发流量（如秒杀）会让权重分配结果在毫秒级就失真
必须靠配套机制补足“感知”和“纠偏”能力
单靠 weight 参数扛不住大并发，关键要组合使用以下三项：
-
least_conn 指令显式启用：在 upstream 块开头加上
least_conn;，Nginx 会先筛选当前活跃连接数最少的候选节点，再在这些节点中按权重二次分发。这对长连接或处理耗时不均的API特别有效 -
健康检查必须主动生效：仅靠
max_fails=3 fail_timeout=30s不够，建议配合proxy_next_upstream error timeout http_500 http_502;和proxy_next_upstream_tries 3;，让一次超时就触发重试+剔除判断 - 权重值要基于实测吞吐量设定：不要按CPU核数拍脑袋定weight=4和weight=1，而应压测出各节点稳定QPS（如A能扛7200 QPS、B能扛2400 QPS），按比例设为 weight=3 和 weight=1
当业务出现明显响应分化，就得换算法
如果监控显示：同一接口，部分请求返回只要80ms，部分卡在2.3s；或者某台机器连接数持续是其他节点的3倍以上，说明加权轮询已无法收敛——它不具备根据RTT或连接状态动态调权的能力。
- 升级到 Nginx Plus 可用
least_time（基于平均响应时间加权） - 自建环境可引入
fair第三方模块（按响应时间分配） - 更彻底的方案是下沉到 service mesh 层，用 Istio 的 DestinationRule 配置基于指标的负载均衡策略
加权轮询是可靠的基础分发器，但不是智能调度器。它在大并发下的表现，取决于你有没有给它配上眼睛（健康检查）、手脚（least_conn）、和校准过的尺子（实测权重）。
