加权轮询是轮询的增强形式，非独立算法；Nginx在upstream中配置weight即自动启用，未设weight者默认为1，所有节点统一纳入加权调度，不支持部分加权与部分纯轮询混用。
加权轮询本身不是“加权”和“轮询”的混合或冲突模式，而是轮询的一种增强形式——它在轮询顺序基础上引入权重因子，不存在配置冲突。所谓“冲突”，通常是因误解默认行为、遗漏关键语法，或混用不兼容参数导致的异常表现。
加权轮询的本质是带权重的轮询调度
轮询（Round Robin）是 Nginx 的默认策略；加权轮询（Weighted Round Robin）是其自然扩展，并非独立算法。只要你在 upstream 块中为任意一台 server 显式指定 weight=，Nginx 就自动启用加权逻辑，其余未设 weight 的服务器默认 weight=1。
- 权重决定每轮中该节点被选中的次数比例，不是绝对优先级
- 例如：
server a:80 weight=3; server b:80 weight=1;→ 每4个请求中，a处理3个、b处理1个，按固定循环序列（a,a,a,b）轮进 - 不支持“部分加权 + 部分纯轮询”这种割裂配置；所有节点统一纳入加权轮询框架
常见误配及修正方式
所谓“冲突”，多出现在以下几种实际配置错误中：
-
混用
ip_hash或least_conn等其他算法指令：一个upstream块内只能启用一种主调度算法。若同时存在ip_hash;和weight=，Nginx 启动会报错或忽略 weight - 权重值为 0 或负数：weight 必须是正整数（如 1、2、5），设为 0 相当于临时下线该节点，但不会触发“冲突”，只是剔除
-
误加
round_robin关键字：Nginx 不需要也不识别round_robin指令；加了反而报错。加权轮询无需开启任何开关，写 weight 即生效 -
与健康检查参数逻辑混淆：如
max_fails和fail_timeout是容错机制，和权重正交共存，不冲突。但若某节点因故障被临时摘除，其权重在剩余节点中重新归一化计算
验证加权是否真正生效
不能只看配置写了 weight，要通过实际流量分布确认：
- 用
curl连续发起 20+ 次请求，记录每次响应头中的自定义标识（如后端返回X-Server-ID: node-a） - 统计各节点出现频次，应接近权重占比（如 weight=3 和 weight=1 → 比例约 75% : 25%）
- 注意：单次请求或低并发下可能因缓存、TCP复用等产生偏差，建议用
ab -c 10 -n 100或wrk测试
合理设置权重的实用建议
权重不是拍脑袋定的数字，需结合真实负载能力：
- 以 CPU 核心数为基准参考：4核服务器 weight=4，2核设为2，1核设为1
- 若某节点内存更大、磁盘更快，可适度上浮权重（如 4核+SSD 可设为5）
- 避免权重差距过大（如 100 vs 1），易造成小权重节点长期空闲或大权重节点过载；建议最大比值控制在 5:1 内
- 上线前做压测，根据平均响应时间反推调整：若某节点 RT 是其他节点的 2 倍，权重可减半
