Nginx 中设置权重比例如何优化后端计算资源分配

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）是否异常上升，可能意味着过载或配置不匹配