用weight参数解决负载倾斜需“按能分”：先依CPU、内存等硬件指标设整数初始权重（如4/2/1），再结合NVMe等优势微调；必须叠加动态反馈，依据CPU使用率、响应时间等实时指标自动调权防失准。
直接用 weight 参数解决异构服务器负载倾斜，核心是让流量分配比例匹配真实处理能力——不是平均分，而是“按能分”。关键不在于设数字，而在于这个数字是否反映服务器此刻的实际吞吐余量。
先按硬件能力设初始权重权重不是拍脑袋定的，要对齐可量化指标。比如三台服务器：CPU核数分别是 16、8、4 → 初始权重可设为 4、2、1内存容量分别是 64GB、32GB、16GB → 同样对应 4、2、1若某台还配了 NVMe SSD，I/O 延迟低 40%，可额外加权 0.5～1 点（如从 4 调到 4.5）
注意：权重只看相对比值，Nginx 中 weight=4/2/1 和 weight=8/4/2 效果完全一样。建议用整数、避免小数，方便后续调整和排查。
用动态反馈机制防权重失准静态权重会失效——比如高配服务器跑满 CPU 后，它实际处理能力已远低于标称值，但权重还是 4，结果越压越垮。必须引入实时信号闭环：监控项选关键瓶颈：CPU 使用率、平均响应时间、5xx 错误率、连接排队长度设定阈值自动调权：例如某节点 CPU > 80% 持续 2 分钟，权重自动降为原值的 50%；恢复至Nginx 本身不支持运行时改 weight，需配合 nginx-upstream-check-module 或外部控制器（如 Consul Template + reload）实现灰度与故障场景下主动干预权重权重是运维杠杆，不止用于日常均衡：上线新版本服务时，先给新节点 weight=1，老节点 weight=10；观察日志和错误率稳定后，再阶梯式调为 3→5→8，同步调低老节点某台机器磁盘 IO 飙高但 CPU 正常？不能只看 CPU，应单独采集 iowait，超阈值即临时降权，避免拖慢整体跨可用区部署时，把延迟低的 AZ 权重设高（如 6），延迟高的设低（如 2），再结合健康检查自动切流验证是否真解决了倾斜别只盯负载均衡器的请求计数，要看后端真实水位：对比各节点每秒请求数（RPS）与它们的权重比是否接近 —— 如果 weight=4/2/1，RPS 应该是近似 4:2:1检查高权重点的平均响应时间是否显著高于低权重点，若是，说明它实际已过载，权重设高了看错误率分布：如果 weight=4 的节点错误率是其他节点的 3 倍，那不是能力问题，是配置或应用问题，权重再调也白搭