加权轮询需动态调优以匹配后端真实能力，权重应基于CPU、RT、QPS等指标设定并控制总和在6–12之间；必须配置max_fails、fail_timeout和slow_start防雪崩；建议结合least_conn或实时负载反馈校准，并定期用请求占比、RT、错误率验证效果。
加权轮询不是设完 weight 就一劳永逸的，它需要结合后端真实能力、响应稳定性与故障恢复机制来动态调优。核心目标是让流量比例真正反映各节点的实际处理能力，避免“权重虚高”或“低权节点长期闲置”。
根据硬件与性能差异合理设置权重
权重不是拍脑袋定的，要基于可观测指标：比如 CPU 核心数、内存带宽、平均响应时间（RT）、QPS 承载上限。若 A 机平均 RT 是 B 机的 1.8 倍，且 QPS 上限低约 40%，那 weight 设为 3 和 2（即 3:2）比设成 5:1 更稳妥。权重比应尽量贴近实际吞吐比，总和控制在 6–12 之间，防止小权重节点（如 weight=1）在大权重主导下几乎收不到请求，失去冗余价值。
必须搭配健康检查参数防雪崩
加权轮询本身不感知后端是否健康，一旦某台高权服务器变慢或卡住，它仍会持续分发大量请求，拖垮整个集群。务必为每个 server 行加上：
- max_fails=3：连续失败 3 次即标记为不可用
- fail_timeout=30s：30 秒内不向该节点转发新请求
- slow_start=60s（可选）：恢复后逐步加大流量，避免刚上线就压垮
例如：server 192.168.1.10:8080 weight=4 max_fails=3 fail_timeout=30s slow_start=60s;
配合 least_conn 或实时指标做辅助校准
纯加权轮询假设所有请求耗时一致，但现实中长连接、文件上传、复杂查询会导致单请求占用资源差异极大。建议在关键业务中叠加 least_conn（最少连接数）逻辑做兜底——Nginx 官方模块虽不直接支持“加权+最小连接”混合算法，但可通过 upstream_hash + 自定义变量，或在应用层埋点上报实时负载，由外部调度器动态调整 weight 值并 reload 配置。
定期验证权重分配效果
上线后不能只看日志轮转顺序，要用真实数据验证：统计每台后端 5 分钟内的请求数、平均 RT、错误率。如果 A（weight=3）请求数占比仅 42%（理论应为 50%），而 RT 比 B（weight=2）高 35%，说明权重偏高，需下调至 2.5 或补强其性能；若 C（weight=1）错误率突增，优先查它是否被误判为健康，而非简单调低权重。
