加权轮询通过按服务器实际能力分配请求优化集群资源利用率，需依据CPU核心数、压测响应时间等科学设权，配合健康检查与日志监控实现动态负载均衡。
加权轮询本身不直接提升单台服务器性能，但它能显著优化整体集群资源利用率——关键在于让强性能机器多干活、弱机器少扛压，避免“木桶效应”拖慢响应速度。
权重设置要贴合真实能力差异
权重不是拍脑袋定的数字，得参考服务器实际硬件指标和历史负载数据：
- CPU核心数差异明显时，可按核心数比例设权重（如8核:4核:2核 → weight=4:2:1）
- 内存或磁盘IO成为瓶颈的应用，建议用压测结果反推：同一接口在各节点的平均响应时间比值，取倒数作为权重参考
- 避免权重悬殊过大（比如100:1），否则小权重节点长期空闲，故障发现滞后，也影响健康检查有效性
配合健康检查机制防止“带病上岗”
加权轮询不会自动跳过宕机或慢节点，必须搭配主动探测才能真正保障质量：
- 每个server行加上max_fails=3 fail_timeout=30s，连续3次失败后剔除30秒
- 对高敏感服务，可启用health_check指令（需Nginx Plus或开源版1.19+配合第三方模块）做HTTP状态码/内容校验
- 注意：权重不变时，被临时剔除的节点恢复后会立即按原权重重新参与分配，无需重启Nginx
避免与least_conn混用导致权重失效
加权轮询只在请求进入时按权重选节点，而least_conn是按当前连接数动态选择。两者不可同时启用：
- upstream块中若写了least_conn，weight参数将被忽略
- 需要兼顾连接负载和能力差异时，优先用加权轮询 + 健康检查；真有连接数倾斜问题，再考虑业务层限流或调整超时参数
- 可通过nginx -T命令验证最终生效的upstream配置，确认weight是否被保留
日志与监控要能区分节点来源
权重调优离不开可观测性，光看总QPS没用，得知道每台机器实际承接了多少：
- 在log_format里加入$upstream_addr和$upstream_response_time，便于分析各节点响应分布
- 用Prometheus + nginx-vts-exporter采集各server的request count、response time、fails等指标，画出权重占比 vs 实际流量占比对比图
- 发现某高权重点实际请求数远低于预期？可能是后端应用启动慢、长连接未释放，或防火墙策略拦截了健康检查探针
