Nginx的weight仅实现请求频次比例分配，非算力均摊；需结合健康检查、least_conn或动态监控调权才能逼近资源均衡，且不可与ip_hash混用。
Nginx 的加权轮询（weight）本身不感知 CPU、内存或响应时间，它只按请求计数做静态比例分发。想让流量分配“匹配不同规格后端的计算力”，关键不是把 weight 当成算力调节器，而是用它做初步能力对齐，再靠其他机制兜底和动态纠偏。
weight 设置要基于可测服务能力
别凭感觉写 weight=10 或 weight=7。真实有效的权重应来自实测数据：
- 用 wrk 或 ab 对每台后端单独压测，记录稳定 QPS（如 A：1500 req/s，B：600 req/s，C：300 req/s）→ 权重比 ≈ 5:2:1
- 若无压测条件，可用硬件指标粗估：双路 16 核服务器 weight=32，单路 4 核 weight=4；SSD 机器比 HDD 机器 weight 可上浮 1.5 倍
- weight 是相对值，3:1:2 和 6:2:4 效果完全一样，无需归一化或凑整到 100
必须搭配健康检查，否则权重失效
一台后端卡死或响应超时，Nginx 不会自动绕过它——除非你明确告诉它怎么判断故障：
- 每个 server 行加上 max_fails=3 fail_timeout=30s：连续 3 次失败（超时/5xx）就标记为 down，30 秒内不再转发
- 这样 weight 才真正在“存活且健康的节点池”里起作用，避免把流量持续打向已瘫痪的机器
- 如果某节点刚恢复，建议加 slow_start=60s，让它在 60 秒内逐步承接流量，防止瞬间压垮
对响应时间敏感的场景，考虑 least_conn 替代方案
当后端处理耗时不均（比如有长任务、数据库慢查询），单纯按请求数分发容易导致负载倾斜：
- least_conn 策略优先选当前活跃连接最少的后端，更适合实际资源占用场景
- 配置很简单：upstream backend { least_conn; server ...; server ...; }
- 它不依赖预先设定的权重，而是实时反映连接压力，更贴近“计算力均衡”的目标
备份与灰度上线也得提前规划
生产环境不能只靠 weight 和健康检查撑全场：
- 用 backup 标记备用机，仅当所有主节点都不可用时才启用，避免误切影响业务
- 维护或升级时用 down 临时下线某节点，它不会参与任何调度，也不计入权重计算
- 新机器上线前先设低 weight + slow_start，观察日志和监控指标稳定后再逐步调高
