加权轮询是nginx实现后端性能差异化调度最直接可控的方式，按服务器实际处理能力分配流量，权重为相对比例而非百分比，需配合least_conn应对长连接，并依据真实负载动态调优。
加权轮询（Weighted Round Robin）是 Nginx 实现后端性能差异化调度最直接、最可控的方式。它不追求“平均”，而是让每台服务器按实际处理能力分担流量，避免高性能节点闲置或低配节点过载。
权重设置要反映真实处理能力
weight 值不是百分比，而是相对比例。比如三台服务器配置为 weight=4、weight=2、weight=1，总权重为 7，对应流量占比约为 57%、29%、14%。关键点在于：
- 新机器 CPU 核数是旧机器的 2 倍，可设 weight=2 vs weight=1；内存或磁盘 I/O 明显更强时，也应相应提高权重
- 未声明 weight 的服务器默认为 1，混用时容易误判整体分配逻辑
- weight=0 可临时下线节点，不参与调度，比注释掉配置更安全灵活
加权轮询需配合 least_conn 应对长连接场景
纯加权轮询按请求次数分配，在文件上传、报表导出等耗时操作多的业务中，可能造成某节点连接堆积、响应变慢。加入 least_conn 后，Nginx 会优先把新请求发给当前活跃连接数最少的节点，与权重协同生效：
- 在 upstream 块中添加 least_conn 指令即可启用
- 注意：least_conn 与 ip_hash 不兼容，二者不能共存
- 适合 WebSocket、大文件 API、后台任务类服务
调优前必须验证后端实际负载特征
权重不是一次设好就一劳永逸。上线后要观察真实指标：
- 检查各节点 CPU 使用率、平均响应时间、连接数是否与预设权重趋势一致
- 若高权重节点响应时间明显上升，说明其瓶颈不在 CPU（可能是数据库连接池、磁盘或网络），此时单纯调高 weight 反而恶化体验
- 有会话依赖（如购物车）的业务，不能只靠 weight，需结合 sticky session 或后端共享 session 存储
避免常见配置陷阱
几个高频出错点直接影响加权效果：
- 误将 weight 当作“百分比”填写，比如填 weight=60、weight=40，结果导致总权重过大、调度周期拉长、响应不敏感
- 在同一个 upstream 中混用 weight 和 ip_hash，Nginx 会忽略 weight，仅执行哈希固定
- 未配置 max_fails / fail_timeout，故障节点无法自动剔除，流量仍会被分过去
