权重设置需基于实测qps等性能指标校准，缩放到1–10区间，配合健康检查动态调整，避免误作流量百分比或忽视单点瓶颈。
权重设置不是拍脑袋填数字，而是让 Nginx 的流量分配逻辑真正匹配后端服务器的实际处理能力。硬件性能差异越大，越需要靠 weight 参数来“校准”负载，否则强节点吃不饱、弱节点被压垮的情况就会出现。
根据真实性能数据设定权重
不能仅凭 CPU 核心数或内存大小估算权重。应基于实测指标（如 QPS、平均响应时间、CPU 使用率）反推相对处理能力：
- 用 ab 或 wrk 对每台后端服务器单独压测，记录相同并发下的稳定 QPS
- 取基准服务器（如最均衡的一台）QPS 为 100%，其他服务器按比例换算：若 A 服务器 QPS 是基准的 1.5 倍，则 weight 设为 15；B 是 0.8 倍，则设为 8
- 避免使用过大权重（如 100/1），建议统一缩放到 1–10 区间，便于后续调整和阅读
动态适配硬件老化与扩容场景
服务器性能会随时间变化，新旧机器混用时权重更需持续校准：
- 上线新服务器后，先设较低权重（如 weight=2），观察 24 小时 CPU 和响应延迟，再逐步提升至目标值
- 老旧服务器出现频繁超时或高负载时，可临时下调 weight（如从 5 降至 3），而非直接下线
- 批量扩容时，不要一次性修改全部权重，采用“加一台、调一次”的渐进方式，防止流量突变引发雪崩
权重必须配合健康检查机制生效
权重只在服务器“健康”状态下起作用。若节点已宕机或响应超时，Nginx 会自动跳过它，此时权重配置就失去意义：
- 在 upstream 块中启用基础被动检查：设置 max_fails=3 fail_timeout=30s，确保连续失败后及时剔除
- 对关键业务建议引入主动健康检查（如通过 nginx_upstream_check_module），定期发 HEAD 请求验证服务可用性
- 注意：ip_hash 或 least_conn 等算法与 weight 共存时，weight 仍参与计算，但调度逻辑优先级不同——加权轮询下 weight 主导，least_conn 下连接数优先，weight 仅作微调参考
避免常见权重误用陷阱
看似简单的 weight 参数，实际容易因理解偏差导致反效果：
- 不要把 weight 当成“流量百分比”硬套：weight=3 和 weight=1 并不等于分得 75% 和 25% 流量，而是按轮次比例分配，实际占比还受请求速率、连接复用、后端响应快慢影响
- 同一 upstream 中，所有 server 必须显式声明 weight，否则未声明者默认为 1，易造成隐性偏差
- weight 不解决单点瓶颈，它只是分配器；若某台服务器本身存在慢 SQL 或 GC 频繁，调高 weight 只会让问题更快暴露
