Nginx的weight仅实现请求频次比例分配，非算力均摊；需结合健康检查、least_conn或动态监控调权才能逼近资源均衡，且不可与ip_hash混用。
权重比例本身不直接优化计算资源分配，它只控制请求分发的理论频次。真正让后端算力更均衡，得靠“权重 + 健康检查 + 连接策略”组合使用，而不是单靠调 weight 数字。
权重要基于可测指标设，不是凭感觉
weight 值没有单位，只看相对大小。设之前先做压测或查硬件规格：
- 用 wrk 或 ab 测出各节点在相同并发下的吞吐（req/s），比如 A 能扛 1200，B 只能扛 300 → 吞吐比 4:1 → weight 设为 4 和 1
- 若服务器 CPU 核数分别是 16C、8C、4C，可粗略按核数比设 weight=4、2、1
- weight=5、3、2 和 weight=10、6、4 效果完全一样，Nginx 自动归一化计算比例
必须搭配健康检查，否则权重再准也失效
weight 不感知 CPU、内存或响应时间。一台 weight=5 的机器如果正在处理慢查询、P95 延迟飙升到 2s，Nginx 仍会继续往它身上派请求，直到触发 max_fails 才暂停。
- 在 upstream 中启用健康检查：max_fails=3 fail_timeout=30s
- 配合 keepalive 连接复用，避免频繁建连放大负载偏差
- weight=0 可临时下线节点，但该节点仍会被健康检查探测
别和 ip_hash 混用，会削弱权重作用
ip_hash 是哈希绑定用户到固定后端，weight 在这种模式下只起备用作用——当某个节点被踢出时，才按权重选替补节点。
- 如果业务没 session 共享或本地缓存依赖，优先用纯 weight + round-robin
- 需要会话保持时，改用 sticky cookie 方案，比 ip_hash 更灵活可控
- least_conn（最少连接）可作为补充策略，尤其适合长连接场景
上线后盯住三项关键指标
调完 weight 不代表万事大吉，得验证实际效果：
- 各节点请求数（$request_number）是否趋近设定比例（需数百次以上请求才稳定）
- 响应时间（$upstream_response_time）有没有明显分化，高 weight 节点是否延迟变长
- 错误率（$upstream_status ≥ 500）是否异常上升，可能意味着过载或配置不匹配
