weight是概率权重而非并发数，需按实测吞吐反推并协同keepalive、max_conns、least_conn等机制；高配服务器不等于高weight，应以cpu/延迟拐点为依据设定，配合健康检查与监控闭环调优。
权重参数本身不直接提升吞吐量，但它决定请求如何分配——配得准，高配服务器才能真正跑满；配得偏，反而会卡住瓶颈、拉低整体吞吐。
weight 是概率权重，不是“多给点请求”的开关
加权轮询（weighted round-robin）下，weight 控制的是被选中的相对概率。比如 weight=6 和 weight=2 的两台机器，理论分发比是 3:1，但实际请求到达节奏还受后端响应速度、连接复用状态影响。若高配机器响应慢（如数据库慢查询未优化），它仍会被持续调度，导致队列堆积、延迟升高，吞吐反而下降。
- weight 不感知后端真实负载，只按比例“投骰子”
- 单次调度不保证严格按比例，长期统计才趋近设定值
- 长连接场景（如 WebSocket）下，weight 影响更滞后——连接一旦建立，后续请求沿用同一后端，直到断开
高配 ≠ 高 weight，要按实测吞吐反推
一台 16 核 64GB 的机器，如果跑的是 GC 频繁的 Java 应用，weight 设成 10 可能刚启动就触发 Full GC；而另一台 8 核 32GB 的 Go 服务，实测稳态吞吐 1800 QPS，weight 设为 9 更合理。关键看单位时间能稳住多少有效请求，而不是硬件参数。
- CPU 密集型：可设 weight=6~12，但必须配合 max_conns 限制并发连接数
- I/O 密集型（如 API 网关）：weight 提升收益有限，优先调 keepalive 和 least_conn 混合策略
- 内存敏感型：weight ≤ 6，建议开启 slow_start，避免冷启动瞬间压垮
单独调 weight 没用，必须配套联动
weight 发挥作用的前提，是连接管理、健康检查和超时机制协同到位。否则高权重节点一旦抖动，流量全涌过去，故障放大效应明显。
- keepalive 32：提升 TCP 复用率，让高配机器真正“忙起来”，而非反复握手空耗
- max_fails=2 fail_timeout=30s：故障快速摘除，防止高权重节点拖垮全局
- 配合 stub_status 或 Prometheus 抓取 upstream_response_time，验证各节点实际响应分布是否贴近 weight 比例（偏差＞15% 就需排查）
怎么配才靠谱：测、算、盯三步闭环
别靠经验拍脑袋。先用 wrk 对单台后端压测，找到 CPU/延迟拐点（比如 CPU 超 75% 时 P95 延迟翻倍），记下此时稳定 QPS；再按比例换算 weight，留 20% 余量；上线后盯监控，看 upstream_addr 分布和响应时间是否对齐预期。
- 例：A 机实测稳态 1500 QPS，B 机 500 QPS → weight 比建议设为 3:1（如 9 和 3）
- 观察 Nginx 日志中 $upstream_addr 和 $upstream_response_time 字段，确认高权重节点没成为延迟热点
- 发现某节点响应时间持续高于均值 2 倍，即使 weight 合理，也要查其 JVM GC、DB 连接池或磁盘 I/O
