高性能服务器weight应基于硬件初估并用压测QPS校准，以最低稳态QPS为基准按比例取整，再配max_fails、fail_timeout和slow_start实现负载均衡与容错。
让高性能服务器在 Nginx 加权轮询中承担更多流量，关键不是“多填几个数字”，而是让 weight 值真实反映它比其他机器多扛多少请求。这个比例得从硬件能力出发、用压测数据校准，再配合健康检查和上线策略，才能稳住效果。
按实测 QPS 设定 weight 才靠谱
硬件参数只能帮你快速初筛，真正决定能分多少流量的，是每台机器在真实业务路径下能稳定输出多少 QPS（每秒请求数）：
- 用
wrk或ab对每台后端单独压测：固定并发数（如 200）、跑满 5 分钟，取不抖动的稳态 QPS（不是峰值） - 选最低 QPS 的节点为基准，设 weight=1；其余节点按比例取整。例如：A=900 QPS、B=450 QPS、C=300 QPS → 比例为 3:1.5:1 → 取整为 weight=6、weight=3、weight=2
- 避免小数或负数——Nginx 不支持，配置会报错；也不必凑总和为 100，它内部自动归一化
硬件指标可作起点，但要打折扣
没条件压测时，可用资源维度粗估，但必须结合应用特征判断权重是否真能兑现：
- CPU：双路 24 核服务器可暂设 weight=48，单路 8 核设为 8；若服务是 I/O 密集型（如文件上传），CPU 核数参考价值就下降
- 内存：某节点内存是其他节点的 2 倍，且应用明显吃内存（比如 Java GC 频繁），weight 可上浮 1.2–1.5 倍
- 磁盘：用 NVMe SSD 的节点，相比同配置 SATA HDD 节点，weight 可设高 1.5–2 倍；全 SSD 环境里混入 HDD，它的 weight 别超过 SSD 节点的 1/3
光设 weight 不够，还得配好这几个参数
weight 是静态比例，但服务器状态是动态的。不加配套机制，再高的权重也容易把流量送进故障节点：
-
max_fails 和 fail_timeout：每个 server 行都加上，比如
max_fails=3 fail_timeout=30s，连续失败 3 次就剔除 30 秒，避免持续发请求 -
slow_start：新上线或刚恢复的高性能节点，加上
slow_start=60s，让流量在 1 分钟内线性增加，防瞬间打满 -
别忽略 keepalive：如果 upstream 开了
keepalive，旧连接可能长期滞留在低配节点上，导致新请求按权重分过去后，实际负载不均衡
注意作用域和算法限制
weight 不是随处可用的万能参数，得看配置位置和负载策略是否支持：
- weight 只能写在
upstream块内的server行里，不能放在location或http块中 - 只在
weight生效的策略下起作用：加权轮询（默认）、least_conn；如果用了ip_hash，weight 会被直接忽略 - 不要混用策略——upstream 块里只能明确指定一种负载方式，轮询、加权轮询、ip_hash 三者互斥
