权重配置本身不直接提升吞吐量上限，但能将请求精准分发至处理能力强的后端，避免强节点闲置、弱节点过载；需基于实测QPS设定、搭配max_fails/fail_timeout健康检查、启用keepalive连接复用，并通过request_number分布、upstream_response_time分位值及error日志持续验证调优。
权重配置本身不直接提升吞吐量上限，但它能让请求更精准地落到实际处理能力强的后端上，从而把已有资源“用满、用对”，避免强节点空闲、弱节点卡死的情况。真正起效的关键，在于测得准、配得稳、盯得住。
按实测吞吐设权重，别看CPU看QPS
一台16核服务器跑Java应用，可能还不如8核Go服务稳定扛压。权重必须基于真实负载能力来定：
- 用 wrk 或 ab 对每台后端单独压测，记录在 CPU ≤75%、P95延迟未明显上升时的稳定 QPS
- 按 QPS 比例设 weight：A 节点 1200 QPS，B 节点 400 QPS → weight 可设为 3 和 1（或 12 和 4，比值一致即可）
- 若某节点内存大但响应慢，以瓶颈指标（通常是 CPU 利用率拐点或平均响应时间突增点）为准，而非硬件参数
权重必须搭配健康检查才不白配
静态权重无法感知后端实时状态。没健康检查，高权重节点一抖动，流量全涌过去，反而放大故障：
- 每个 server 行都加上 max_fails=2 fail_timeout=30s，连续失败两次即暂停调度
- 配合 slow_start=10s，让刚恢复的节点逐步承接流量，防雪崩
- weight=0 可临时下线，但该节点仍会被健康检查探测，适合灰度或维护场景
连接复用不到位，权重就只是个摆设
每次请求都新建 TCP 连接，握手开销远大于调度逻辑本身，权重再准也失去意义：
- upstream 块中必须加 keepalive 32（数值参考后端连接池容量 × 0.6～0.8）
- 对应 location 中设置 proxy_http_version 1.1 和 proxy_set_header Connection ''
- 确认后端返回响应头含 Connection: keep-alive，且其 keep-alive timeout > Nginx 的 keepalive_timeout
上线后靠三项指标验证是否真有效
配完不是结束，而是调优闭环的开始。重点看：
- 各 upstream server 的 $request_number 分布：长期统计是否接近设定权重比（偏差＞15% 就要排查）
- $upstream_response_time 分位值：高权重节点 P95 延迟不应显著高于低权重节点
- error.log 中 “upstream timed out” 或 “no live upstreams” 报错：出现说明某节点持续过载，权重可能偏高或存在未发现瓶颈（如慢 SQL、GC 频繁）
