应通过压力测试实测p95延迟与qps确定权重，以基准机p95为分母计算各节点权重并取整，避免理论比例失真；需验证日志分发占比与后端监控，结合硬件/应用优化动态微调权重，最大权重比不宜超过1:4。
不同年份的 CPU（比如 Intel Xeon E5-2680 v2 和 EPYC 9654）性能差异大，不能按型号或核心数直接设权重。真实承载能力取决于整条链路——应用逻辑、JVM GC、数据库连接池、磁盘 IO 等都可能成为瓶颈。必须用压力测试实测响应能力，再反推权重。
用 wrk 实测每台后端的 P95 延迟和稳定 QPS
在相同环境（同网段、无其他干扰流量）、相同压测参数下对每台后端单独压测：
- 统一命令：wrk -t4 -c100 -d30s --latency http://192.168.1.x:8080/api/health
- 重点看输出中的 Latency Distribution 下的 P95 值（单位 ms），以及 Requests/sec（QPS）
- 若某台在 P95
以基准机为锚点，算出整数权重比
选一台表现最稳、P95 最低的机器作基准（例如新 EPYC 机 P95 = 65ms），其余节点权重 = 基准 P95 ÷ 自身 P95，四舍五入为正整数：
- EPYC 9654：P95 = 65ms → weight = 65 ÷ 65 = 1
- Xeon E5-2680 v2：P95 = 195ms → weight = 65 ÷ 195 ≈ 0.33 → 取整为 1
- 老 Atom 服务器：P95 = 420ms → weight = 65 ÷ 420 ≈ 0.15 → 取整仍为 1
此时三台都设 weight=1，说明它们在该接口上实际处理能力接近，强行拉成 8:2:1 反而导致老机器被压垮、新机器闲置。
验证权重是否真起作用，别信理论比例
reload 后不能只看配置生效，要观察真实分发效果：
- 等至少 500 次请求后，执行：awk '{print $upstream_addr}' /var/log/nginx/access.log | sort | uniq -c | sort -nr
- 对比各 IP 出现次数是否趋近理论占比（如 5:3:2 配置下，应接近 50% : 30% : 20%）
- 同时查对应后端监控：若某台 CPU 持续 95% 但权重仅 2，说明它存在慢 SQL 或锁竞争，需单独优化应用，不是调权能解决的
上线后每周微调，尤其硬件升级后
权重不是一锤定音的静态值：
- SSD 升级后，某台 P95 从 240ms 降到 110ms，可将其 weight 从 2 提到 4（提升约 80%，与延迟改善幅度匹配）
- Java 应用加了 G1 GC 调优后 RT 下降 35%，也建议同步上调权重 20%～30%
- 避免最大权重比超过 1:4（如 4:2:1 可行，8:1:1 不推荐），保留故障时的弹性空间
