直接用weight参数就能实现按比例分发，它不依赖额外模块，也不需要实时监控系统，关键在于设得准、配得全、验得实；权重为正整数、仅在upstream块内server指令后生效，需结合压测qps设定相对比例，并搭配max_fails、slow_start等容错与连接策略协同生效。
直接用 weight 参数就能实现按比例分发，它不依赖额外模块，也不需要实时监控系统，关键在于设得准、配得全、验得实。
权重值怎么设才合理
weight 是无量纲整数，只看相对大小，不是百分比，也不是绝对性能值。设之前建议参考可测指标：
- 用 wrk 或 ab 做压测，比如 A 节点 QPS=1200，B=300 → 吞吐比 4:1 → weight 设为 4 和 1
- CPU 核心数分别是 16C、8C、4C，可粗略对应 weight=4、2、1
- 避免用太小的数字（如 1 和 2），推荐统一放大（如 20:10:5），减少低流量下因连接复用或四舍五入带来的偏差
- weight=0 可临时下线节点，健康检查仍会探测它
配置必须写对位置
weight 只能在 upstream 块内的 server 指令后使用，写错地方 Nginx 会报错：
- ✅ 正确：
upstream app { server 192.168.1.10:8080 weight=4; } - ❌ 错误：写在 location 块里、proxy_pass 行后，或绕过 upstream 直接 proxy_pass 到 IP
- upstream 必须定义在 http 块内，且不能嵌套在 server 或 location 中
单靠 weight 不够，得加容错和连接策略
weight 只管“正常时怎么分”，不管“出问题了怎么办”：
- 搭配
max_fails=3 fail_timeout=30s：连续失败 3 次就暂停转发，故障期间剩余节点按权重重新归一化分担 - 新节点上线用
slow_start=30s，让流量从 0 缓慢爬升，防冷启动冲击 - 长连接或耗时请求多时，加
least_conn—— Nginx 优先选当前活跃连接最少的节点，和 weight 协同更公平 - 别和
ip_hash混用，否则 weight 只在节点被踢出时起备用作用
上线后盯住这三项指标
调完 weight 不代表结束，得验证实际效果是否贴近预期：
- 各节点请求数（
$request_number）是否趋近设定比例，需数百次以上请求才稳定 - 响应时间（
$upstream_response_time）有没有明显分化，高 weight 节点延迟是否反升 - 错误率（
$upstream_status ≥ 500）是否异常上升，可能意味着过载或配置失配
