权重分发本身不直接提升单点可靠性，但通过按真实能力切分流量避免强机空转、弱机过载，减少雪崩与级联失败；必须配合被动健康检查（max_fails/fail_timeout、proxy_next_upstream）和least_conn策略，并依赖监控验证与灰度调整实现真正可靠。
权重分发本身不直接提升单点可靠性，但能让集群整体更稳——它把流量按真实能力切分，避免强机空转、弱机过载，从而减少因局部过载引发的雪崩、超时和级联失败。
权重必须配合健康检查才真正可靠
光设 weight=5 和 weight=1 没用，如果高权重点响应变慢或假死，Nginx 还会持续往里塞请求。必须启用被动健康检查：
- 每个 server 后加 max_fails=2 fail_timeout=15s：连续 2 次失败（如超时或 5xx）就剔除 15 秒；
- 在 location 块中配 proxy_next_upstream error timeout http_500 http_502 http_503 http_504：任一后端出问题，自动转给下一个加权节点；
- weight=0 可临时隔离节点，但保留健康探测，便于快速恢复。
least_conn 是长连接场景下的可靠性补丁
纯 weight + 轮询对短平快接口够用，但遇到文件上传、报表导出等耗时请求，连接堆积会导致响应延迟飙升甚至超时。least_conn 能动态避开繁忙节点：
- upstream 中先写 least_conn，再列带 weight 的 server；
- 它不替代权重，而是“在连接数相近时才按权重分”，既保公平又防堆积；
- 注意不能和 ip_hash 共存，否则 least_conn 失效。
验证和校准比配置更重要
上线后不看数据，权重就是纸上谈兵。真正提升可靠性靠的是闭环反馈：
- 用 stub_status 或 nginx-vts-exporter + Prometheus 看各节点 active 连接数、request rate、failures；
- 对比日志中各实例实际请求数，是否接近 weight 比例（如 4:2:1 → 实际应为 ~57% : ~29% : ~14%）；
- 若高权重点 P95 延迟反超低权重点，说明它存在慢查询或资源争用，要查服务本身，而不是调低 weight 掩盖问题。
灰度调整比一次性设值更稳妥
新机器上线、大促压测、硬件升级后，权重不能一步到位：
- 新节点先设 weight=1，观察 10–15 分钟响应时间与错误率；
- 确认稳定后再逐步调高，每次增幅不超过原值的 50%；
- CPU 持续 >70% 或连接数长期高于其他节点 2 倍，就要考虑降权或扩容，而非硬扛。
