权重分配是调节流量匹配后端能力的杠杆，需结合健康感知与请求特征；应基于压测qps等量化指标设正整数权重，配max_fails/fail_timeout容错，并按业务选ip_hash/least_conn等策略，上线后用500+请求验证分布偏差。
权重分配本身不是性能“最大化”的魔法开关，而是让流量更贴合后端真实能力的调节杠杆。真正提升整体性能，靠的是权重 + 健康状态感知 + 请求特征匹配的组合动作。
权重设置必须基于可量化的性能差异
不能凭感觉设 weight=10，否则反而造成失衡。建议先做基准压测：
- 对每台后端单独用 wrk 或 ab 测试：记录在相同并发下吞吐（QPS）、平均延迟和错误率
- 以性能最优节点为基准（比如 QPS=1200），其余节点按比例折算权重：若另一台 QPS=600，则 weight 可设为 1200:600 = 2:1 → weight=2 和 weight=1
- 避免小数或浮点权重——Nginx 只接受正整数，用最小公倍数统一换算（如 3:1.5 → 2:1）
权重必须搭配故障隔离机制才有效
光分流量不防宕机，高权重节点一旦出问题，影响会被放大。务必同步配置容错参数：
- max_fails 和 fail_timeout 必须成对出现：例如 max_fails=3 fail_timeout=30s 表示连续失败3次后，30秒内不再转发请求
- 高权重节点可适当降低 fail_timeout（如设为 15s），让它更快恢复参与调度
- 加 down 标记临时下线维护中的机器，加 backup 设置灾备节点，它们不参与日常权重计算
根据请求类型选策略，别只靠 weight
单一加权轮询无法应对所有场景，需按业务特征叠加其他策略：
- 带会话的应用（如登录态）→ 用 ip_hash，此时 weight 仅在某节点失败后起备用选择作用
- 长连接服务（如 WebSocket、gRPC）→ 改用 least_conn，比权重更能反映实时负载
- 静态资源或缓存友好型接口 → 用 hash $request_uri consistent，提升缓存命中率，间接减轻后端压力
上线后必须验证真实分布
权重是概率倾向，不是精确计数。验证不能只看一次请求：
- 用 curl -I 或简单脚本发起至少 500 次以上请求
- 检查各后端 access log 中 $remote_addr 或自定义 header（如
proxy_set_header X-Upstream-Name $upstream_addr;） - 统计实际请求数占比，与理论权重比（如 3:1 → 75% vs 25%）偏差超过 ±8% 就需复核配置或后端响应一致性
