加权轮询是轮询算法的增强形态，按权重比例扩展槽位序列实现有序分发；例如weight=3、2、1对应调度序列a-a-a-b-b-c循环，权重为正整数且默认值为1。
带权重的轮询不是“混合场景”，而是轮询算法的增强形态——Nginx 的 加权轮询（Weighted Round Robin） 本身就是轮询的自然扩展，它在保持请求顺序性的同时，按权重比例放大分配频次。
加权轮询的本质逻辑
它不是先轮询、再加权，也不是两种策略并存；而是把每台服务器看作一个“槽位集合”：权重为 n 的服务器，在一轮完整调度周期中占据 n 个槽位。Nginx 按照这个扩展后的序列循环分发请求。
- 例如：
server A weight=3; server B weight=2; server C weight=1→ 总权重=6 → 实际调度序列为 A-A-A-B-B-C，然后重复 - 请求第1、2、3个落到A，第4、5个落到B，第6个落到C，第7个又回到A……严格有序，但比例可控
- 这种机制天然兼容健康检查：某台服务器宕机时，Nginx 自动跳过其所有槽位，其余服务器按剩余权重比例继续服务
配置时的关键细节
权重必须是正整数，且不支持小数或动态变量（如 $upstream_addr）。实际部署中要注意：
- 权重值本身无绝对意义，只反映相对处理能力。weight=10 和 weight=100 效果等同于 1:10 的比例关系
- 若未显式声明
weight，默认为 1，即退化为标准轮询 - 可与
max_fails和fail_timeout配合使用，实现故障自动摘除，避免“带病参与权重分配”
怎么应对真实异构环境
权重不能靠拍脑袋定。建议结合后端服务器的实际指标设定：
- CPU核心数比：若 A 是 16 核、B 是 8 核、C 是 4 核，初始权重可设为
4:2:1 - 压测吞吐量比：实测 A 单机 QPS=1200、B=800、C=400 → 权重比 ≈
3:2:1 - 上线后观察各节点负载（CPU、响应时间、连接数），用
nginx -s reload动态调整权重，无需重启
和纯轮询共存？不需要
你不需要也不应该在一个 upstream 块里混用“带 weight”和“不带 weight”的 server 行来制造“混合”。Nginx 统一按加权逻辑处理——未设 weight 的视为 weight=1，整个组自动进入加权轮询模式。所谓“混合”，其实是对权重机制理解偏差导致的误操作。
