负载均衡(Load Balance):其实就是将请求分摊到多个操作单元上进行执行,从而共同完成工作任务。具体实现上,Dubbo 提供的是客户端负载均衡,即由 Consumer 通过负载均衡算法得出需要将请求提交到哪个 Provider 实例。
负载均衡策略
LoadBalance接口及实现类结构图
可以看出抽象的负载均衡下的类分为4个,这4个类表示了4种负载均衡策略,分别是一致性Hash均衡算法、随机调用法、轮询法、最少活动调用法。
算法 | 特性 | 备注 |
---|---|---|
random | 加权随机 | 默认算法,默认权重相同 |
RoundRobinLoadBalance | 加权轮询 | 借鉴于 Nginx 的平滑加权轮询算法,默认权重相同 |
LeastActiveLoadBalance | 最少活跃优先 + 加权随机 | 背后是能者多劳的思想 |
ShortestResponseLoadBalance | 最短响应优先 + 加权随机 | 更加关注响应速度 |
ConsistentHashLoadBalance | 一致性 Hash | 确定的入参,确定的提供者,适用于有状态请求 |
Random LoadBalance:加权随机
- 按照概率设置权重,比较均匀,并且可以动态调节提供者的权重。
RoundRobin LoadBalance:轮询
- 轮询,按公约后的权重设置轮询比率。会存在执行比较慢的服务提供者堆积请求的情况,比如一个机器执行得非常慢,但是机器没有宕机(如果宕机了,那么当前机器会从ZooKeeper 的服务列表中删除)。
- 当很多新的请求到达该机器后,由于之前的请求还没处理完,会导致新的请求被堆积,久而久之,消费者调用这台机器上的所有请求都会被阻塞。
LeastActive LoadBalance:最少活跃调用数
- 如果每个提供者的活跃数相同,则随机选择一个。
- 在每个服务提供者里维护着一个活跃数计数器,用来记录当前同时处理请求的个数,也就是并发处理任务的个数。这个值越小,说明当前服务提供者处理的速度越快或者当前机器的负载比较低,所以路由选择时就选择该活跃度最小的机器。
- 如果一个服务提供者处理速度很慢,由于堆积,同时处理的请求就比较多,也就是说活跃调用数较大,处理速度慢。这时,处理速度慢的提供者将收到更少的请求。
ConsistentHash LoadBalance一致性Hash策略
- 一致性Hash,可以保证相同参数的请求总是发到同一提供者,当某一台提供者机器宕机时,原本发往该提供者的请求,将基于虚拟节点平摊给其他提供者,这样就不会引起剧烈变动。
配置
配置负载均衡策略,既可以在服务提供者一方配置,也可以在服务消费者一方配置。
客户端服务
xml配置:
<dubbo:service interface="TestService" loadbalance="roundrobin" />
指定TestService服务的调用方式为加权轮询
注解配置:
通过Reference注解中的loadbalance属性来指定负载均衡的策略
@Reference(check = false, loadbalance = "random")
private TestService testService;