权重调度不保证精确均衡，需结合健康检查、连接状态感知和性能验证；weight应基于压测吞吐量或硬件资源设定，灰度发布可设weight=1与9实现10%流量切入，必须配置max_fails和fail_timeout，并辅以least_conn或ip_hash等策略。
权重调度本身不保证“精确均衡”，它只确保请求按设定比例分发。真正实现流量与后端实际承载能力匹配，需要把 weight 作为起点，再叠加健康检查、连接状态感知和合理验证机制。
权重设置必须基于可测性能指标
别用主观判断设 weight=10 或 weight=99。有效做法是：
- 对每台后端压测：用 wrk 或 ab 测出稳定吞吐量（如 A 为 1500 req/s，B 为 600 req/s），取比值 1500:600 ≈ 5:2，对应 weight=5 和 weight=2
- 按硬件资源粗估：8 核服务器设 weight=8，4 核设 weight=4；32GB 内存可设 weight=16，16GB 设 weight=8（按 GB/2 取整）
- 灰度发布时，新实例 weight=1、老实例 weight=9，自然达成 10% 流量切入，无需改代码或路由规则
单靠 weight 会失效，必须绑定健康检查
哪怕 weight 配得再准，如果一台机器卡死在慢响应上，Nginx 还会继续按比例派请求过去。所以每行 server 必须带故障探测参数：
- max_fails=3：连续 3 次超时或返回 5xx，就标记该节点为 down
- fail_timeout=30s：30 秒内不再转发请求，之后自动试探恢复
- 可配合 down 手动下线维护中的节点，或用 backup 标记灾备机，仅主池全不可用时启用
更贴近真实负载的补充策略
当后端响应时间差异大、或存在长耗时任务时，仅靠 weight 不够，建议组合使用：
- least_conn：优先发给当前活跃连接最少的后端，适合长连接场景（如 WebSocket、HTTP/2 流）
- ip_hash：固定用户到同一台机器，适用于未做 session 共享的登录态服务
- 若需动态响应时间加权，得依赖 Nginx Plus 或 OpenResty + Lua 自定义 balancer，开源版不支持
配置生效后要验证是否真按比例走量
改完配置 reload 后，不能只看语法是否通过。实际验证方法：
- 用 curl -I 多次请求，观察响应头中 Server 或 X-Backend 字段，统计各 IP 出现频次（采样 ≥1000 次）
- 查 access.log，用 awk + sort 统计 upstream_addr 字段分布，看是否接近理论占比（允许 ±5% 偏差）
- 避免权重差距过大（如 1 和 100），否则小权重节点可能几十秒都收不到请求，失去调度意义
