权重设置是动态调节流量分配的杠杆，需依据硬件能力设初始值、结合least_conn应对长连接、通过健康检查保障节点可用性，并持续灰度调整与监控验证。
权重设置本身不直接“实现性能最大化”，而是让流量分配更贴近各节点真实处理能力，从而在整体上提升集群吞吐、降低延迟、减少失败率。关键在于把 weight 当作一个可调的杠杆，而不是一劳永逸的数字。
按硬件能力设定初始权重
权重应反映节点间相对计算能力，比如 CPU 核心数、内存容量、磁盘 I/O 性能等。若新节点是旧节点性能的 2 倍，weight 就设为 2:1；三台异构机器配比为 4:2:1，对应约 57%、29%、14% 的长期请求占比。
- 避免凭空设值（如全设为 10），需有压测或历史监控依据
- 同一型号机器默认用 weight=1 即可，无需人为放大
- 测试环境建议从 weight=1 开始，上线后再逐步调高
结合 least_conn 应对长连接场景
纯加权轮询在文件上传、WebSocket 或报表导出类业务中容易导致连接堆积——某节点虽权重高，但大量请求未释放，实际已过载。least_conn 能动态将新请求导向当前活跃连接最少的节点，与 weight 协同工作：
- 在 upstream 块开头添加 least_conn; 指令
- 不能和 ip_hash 共存，二者策略冲突
- 特别适合后端响应时间波动大、连接生命周期长的业务
用健康检查保障权重只作用于可用节点
如果一台 high-weight 节点响应缓慢或返回 502/504，继续往它身上分发流量反而拖垮整体。Nginx 提供被动健康检查机制：
- 每个 server 行加上 max_fails=3 fail_timeout=30s，表示连续失败 3 次后剔除 30 秒
- 配合 proxy_next_upstream error timeout http_500 http_502 http_503 http_504，失败时自动切到下一个候选节点
- 剔除期间，剩余节点按原有权重比例重新分摊流量，系统自动降级而不中断
灰度调整 + 监控闭环验证效果
权重不是上线就固定不变的参数。随着扩容、升级或业务变化，需要持续观察并微调：
- 上线新节点初期设 weight=1，观察 1–2 小时的 CPU 使用率、平均响应时间、错误率
- 确认稳定后再阶梯式上调（如 1→2→4），每次调整后保留足够观察窗口
- 核心监控指标：各节点的 active connections、request per second、5xx rate、upstream_response_time
- 避免单次调幅过大（如从 1 直跳 10），易引发瞬时抖动
