加权轮询的weight应基于实测QPS设定，如A(1500 QPS)、B(600 QPS)对应weight 5和2；硬件参数仅作初筛，须搭配健康检查（max_fails=3, fail_timeout=30s）并避免小数、负数及keepalive导致的实际过载。
加权轮询的 weight 不是随意填的数字，它本质是让流量按比例倾斜，前提是这个比例得反映真实服务能力。直接按CPU核数或内存大小拍脑袋设值，容易导致高配机器吃不饱、低配机器被压垮。
基于实测吞吐量定权重最靠谱
不同配置的服务器，响应能力差异最终体现在单位时间能稳定处理多少请求（QPS）。这才是决定 weight 的硬指标：
- 用 wrk 或 ab 对每台后端单独压测：固定并发数（如 200），跑 60 秒，记录平均 QPS 和 P95 延迟
- 假设 A 服务器稳定扛住 1500 QPS，B 服务器只能到 600 QPS，则 QPS 比为 1500:600 = 5:2 → weight 可设为 5 和 2
- 如果有三台：A(1800 QPS)、B(900 QPS)、C(300 QPS)，比值约 6:3:1，weight 就设 6、3、1
硬件参数可作初筛，但不能替代压测
在没条件压测时，可用硬件指标快速估算，但要打折扣、留余量：
- CPU：双路 16 核（32 线程）服务器，weight 可暂设 4；单路 4 核设为 1。注意：若应用是 I/O 密集型，CPU 核数参考价值就下降
- 内存：若某节点内存翻倍且应用明显受堆内存限制（比如 Java 服务 GC 频繁），weight 可上浮 1.2–1.5 倍
- 磁盘：全 SSD 集群中混入一台 HDD 服务器，它的 weight 建议不超过 SSD 节点的 1/3，避免慢盘拖累整体响应
权重必须搭配健康检查才有效
再合理的 weight，如果后端挂了还在持续转发，等于白配。每个 server 行至少加上基础容错：
- max_fails=3：连续 3 次超时或返回 5xx，就标记为不可用
- fail_timeout=30s：进入不可用状态后，30 秒内不发新请求，之后自动试探恢复
- 示例：server 192.168.1.10:8080 weight=5 max_fails=3 fail_timeout=30s;
避免常见权重陷阱
几个高频出错点，直接影响效果：
- weight 写成小数或负数——Nginx 不支持，会报配置错误
- 设 weight=100 和 weight=1，看似比例大，但实际和 10:1 效果一样，反而掩盖真实比值关系
- 只调 weight，却不关掉 keepalive 连接复用，旧连接堆积在低配节点上，新请求又按权重继续分过去，造成“表面均衡、实际过载”
