用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 倍，那不是能力问题，是配置或应用问题，权重再调也白搭