加权轮询调度算法的核心思路，就是让每个后端实例根据自身处理能力的强弱，领取不同比例的请求，能力强的多干活，能力弱的少操心。
这个机制解决了一个很实际的问题：当集群里机器配置参差不齐时，按人头平均分配反而是最大的不公平，高性能机器闲着，低配机器累垮，整体吞吐量上不去，加权轮询要做的，就是把“按人头分”升级成“按本事分”。
加权轮询调度算法原理：从“轮流坐庄”到“按劳分配”
要先理解加权，得先回顾普通轮询，普通轮询就是维护一个队列，来一个请求发给A，下一个发给B，再下一个发给C，循环往复，它假设所有实例的CPU、内存、网络带宽完全一致,这在云原生和混合部署时代几乎不成立。
加权轮询给每个实例设定一个权重值，这个值不是拍脑袋定的，通常是依据实例的规格（如CPU核数、内存大小、网络连接数上限）计算出来的基准分，权重为5的实例，在同一个时间窗口内应承接的请求数量，是权重为2的实例的2.5倍。
核心分配规则如下：
- 每个实例预设权重
weight，同时初始化当前有效权重current_weight为 0。 - 每次请求到来时，所有实例的
current_weight都加上自己的weight。 - 选中
current_weight最大的实例接收请求。 - 被选中的实例，其
current_weight需要减去所有实例的weight总和。
这个逻辑听起来有点绕，但它能保证生成平滑的调度序列，举个具体例子，A实例权重4，B实例权重1，C实例权重1，那么连续6个请求的分配序列不是“AAAABC”那种急迫的冲击，而是会平滑交错，A B A C A A”，这样就避免了某个高权重实例在一瞬间被打满，而低权重实例在旁边歇着的情况，业内专家指出，这种平滑特性对于WebSocket长连接和数据库连接池密集型应用尤其重要。
配置nginx加权轮询策略时的权重设计思路
多数场景下，我们不需要自己手写算法，Nginx和LVS都已经内置了成熟的实现，重点是学会配置,以及理解配置背后的权重比例设计。
在Nginx的 upstream 块中,配置是非常直观的：
upstream backend {
server 192.168.1.10 weight=4;
server 192.168.1.11 weight=2;
server 192.168.1.12 weight=1;
}配置本身不需要解释，需要深入想的是
权重值如何确定,这直接影响到调度效果。
首先看静态权重设定，如果后端的云服务器一个是8核16G，一个是4核8G，在同样的业务逻辑下，权重设置为4:2是合理的，不是写8和4，而是看处理能力的倍率，但更稳妥的做法是压测，你可以在低峰期对两个节点同时施压，测出各自的最大QPS（每秒请求数），假设A节点极限 2000 QPS，B节点极限 1000 QPS，那么权重就设为 2:1，这是最客观的依据,也是将算法落地的关键。
针对慢接口的降权处理，如果某个节点的CPU使用率总是偏高，或者磁盘IO等待时间过长，即使它在轮询队列里正常，也应该手动下调权重。 加权轮询不感知实时负载，它只认配置,调权是正确的介入手段。
在微服务架构的网关（如Spring Cloud Gateway或Dubbo）中，权重配置通常不在配置文件里写死，而是通过注册中心（如Nacos）的元数据动态下发，通过控制台上的管理操作，为不同版本或不同规格的实例下发不同的 weight 值，然后网关在本地缓存这些权重信息，定时刷新。热门电商大促场景中，这种动态调权配合限流组件,能有效防止流量倾斜压垮单节点。
加权轮询算法和随机算法对比：何时该用哪种
很多人会把加权轮询和加权随机搞混，两种算法都能实现“按比例分发”,但产生的瞬间流量特征不同。
加权随机算法每次请求来临都独立抽签，抽签概率等于权重占比，这意味着在短时间窗口内（比如1秒内），可能会连续多次抽中同一个高权重节点，造成瞬时抖动，而加权轮询算法通过上面提到的 current_weight 修正，保证了在一个调度周期内,请求是均匀打散的。
| 对比维度 | 加权轮询算法 | 加权随机算法 |
|---|---|---|
| 分配序列 | 固定顺序循环，平滑 | 随机命中，有概率出现集中请求 |
| 瞬时负载 | 均衡，能避免短时毛刺 | 可能出现短时倾斜 |
|
实现复杂度 |
稍高，需维护状态 | 极低，只需一次随机数计算 |
| 适用场景 | 对响应时间波动敏感的业务 | 日志采集、异步任务分发等容忍抖动的场景 |
至于与哈希算法的区别，哈希是为了保持会话粘滞，确保同一个用户的请求总是落在同一台机器上，它的核心诉求是“一致性”，而不是“均衡性”，而加权轮询的核心诉求只有“均衡”。
哪种场景优先选择加权轮询？行业共识认为，当你的服务是无状态服务时，它是分布式网关负载均衡策略中最稳妥的默认选项，比如内部RPC调用、API网关转发，业务不依赖本地Session，适合平滑轮询，如果你的业务强制要求客户端IP或用户ID必须固定访问某台实例（比如本地缓存了用户资料）,那么请移步一致性哈希算法。
解决加权轮询中的两大易踩坑点
加权轮询虽然经典，但在实际运维中如果不注意细节,很容易出问题。
第一个坑是权重归零后的摘除逻辑，在Nginx的轮询中，如果某个实例的 weight 设为0，默认它还会接收请求吗？实际上是不会的，设为0表示该节点不参与新的请求调度，但要注意，如果该节点正在处理长请求，新的请求不会再上来，这是符合预期的，但在动态调整权重的API中，要确保代码逻辑是“设置0即摘除”，而不是通过把权重调到极小值来实现（比如调到1），那依然会分到微量流量，这对于需要全量下线重启的场景非常致命。
第二个坑是慢启动导致的超时误判，当新实例启动后，它的权重如果直接加入轮询池，可能会被瞬间涌入的大量请求打懵，因为JVM或Go Runtime的预热需要一段时间，比较务实的做法是设置预热时间，Nginx商业版里有 slow_start 参数，开源的版本里没有，这时可以通过自动运维脚本，在实例启动的前5分钟逐渐将权重从1提升至目标值，相当于手动实现了一个平滑预热，配合熔断策略很关键：如果某实例连续返回5xx错误超过阈值，网关应临时将其权重降为0,待心跳恢复后再放量。
基于权重分配请求的落地医疗与电商实践参考
纸上谈兵无用,把算法映射到具体业务验证是更好的方式。
在医疗挂号系统的高并发抢号场景，后端接口非常吃数据库连接，假设主库实例性能强劲，从库实例稍弱，入口网关采用加权轮询。系统运维人员会在每个季度大促前做一次全链路压测，根据压测报告动态调整权重，压测报告显示A节点连接池利用率超过80%时，就削减该节点权重，将流量引导至利用率低于30%的节点，这种基于实例能力评估的调整,能让集群的整体资源利用率稳定在较高水平。
而在电商大促的海量商品详情页请求中，静态文件走CDN，动态价格接口走网关，如果沿用默认的 weight=1，几台不同代际的服务器（比如物理机与容器混部）之间会出现性能倒挂，通过容器管理平台为不同规格Pod打上Label，监控系统收集CPU使用率、Load Average和P99延迟，由算法自动计算健康权重，再调用网关API下发配置,这里推荐一个实用的操作步骤：
- 在Prometheus中设置CPU使用率超过 70% 的告警规则。
- 编写脚本监听告警，自动调用Nacos Open API将对应实例的权重下调 20%。
- 等待5分钟观察队列堆积长度。
- 如果堆积仍未缓解，继续下调 30%,直至流量均衡。
加权轮询调度常见问题解答
为什么有时候权重高的机器CPU使用率反而比权重低的高出很多？
因为权重是按静态能力算的，如果高权重机器上的一个请求耗时为低权重机器请求的3倍，那么即便请求数量是2倍，CPU消耗也会达到6倍，此时需要检查集群中是否存在热点数据或长尾请求，仅仅调整权重已无法解决根源问题，可能需要对请求按业务ID进行分片，或者使用最少连接数算法来感知实时负载。
Nginx中 backup 参数和设置 weight=0 有什么区别？
backup 是备份服务器配置，当所有主节点全部宕机或down掉时，流量才会导入到 backup 节点，而 weight=0 是指该节点不参与正常调度，但节点本身在Nginx视角里是存活的，依然会执行健康检查，如果你希望节点在空闲时保存连接上下文，但不想接流量，用 backup 更为合适；如果只是临时检修，改权为0更直接。两者正好对应了容灾降级和日常发布的场景。