weight参数应基于实测qps设定，如1500:600→5:2；无压测时按硬件保守估算，cpu双路16核设为4、单路4核为1，ssd节点权重hdd不超1/3，内存翻倍可上浮20%–50%；语法须严格，weight=5不可加空格或引号，仅支持正整数且需配合健康检查使用。
weight 参数不是按CPU核数或内存大小直接换算的，而是反映服务器在真实业务场景下能稳定处理多少请求。核心是让数值比例接近各节点的实际服务能力比。
优先用实测QPS定权重
最可靠的方式是对每台后端单独压测，用 wrk 或 ab 工具跑固定并发（如200）、持续60秒，记录稳定QPS和P95延迟：
- A服务器实测稳定1500 QPS，B服务器600 QPS → 比例1500:600 = 5:2 → weight设为5和2
- 三台服务器QPS分别为1800、900、300 → 约简得6:3:1 → weight写6、3、1
- 压测时注意观察延迟是否突增，QPS要取“不明显拖慢响应”的上限值，不是峰值冲高就停
没条件压测时按硬件粗估但必须打折
硬件参数只能作参考，实际性能受磁盘IO、网络、应用逻辑影响很大，建议保守估算：
- CPU：双路16核服务器暂设weight=4，单路4核设为1；别直接按32核写weight=32
- 磁盘：全SSD集群中混入HDD节点，weight别超过SSD节点的1/3
- 内存：若某节点内存翻倍且服务明显内存敏感（如Java堆大、缓存多），weight可适度上浮20%–50%，但不翻倍
配置写法和常见陷阱
weight语法极严格，错一个字符就失效：
- ✅ 正确：server 192.168.1.10:8080 weight=5 max_fails=3 fail_timeout=30s;
- ❌ 错误：weight = 5（等号前后有空格）
- ❌ 错误：weight="5"（加引号）
- weight必须是正整数，不支持小数；它只看比值，weight=30和weight=3效果一样
- 不能和backup或down同时使用——逻辑互斥，用了backup就不再参与加权轮询
必须搭配健康检查才真正起作用
再准的weight，如果后端挂了还在转发，等于白设：
- 每个server都应带max_fails=3 fail_timeout=30s，连续3次超时或5xx即剔除
- 所有节点统一提供/health接口，并在location中配proxy_next_upstream error timeout http_500;实现自动重试
- 新上线或恢复节点建议加slow_start=30s，避免刚恢复就被流量打垮
