大家好，又见面了，我是你们的朋友全栈君。
文章目录
- 前言
- 1. 什么是负载均衡
-
- 1.1:负载均衡简介
- 1.2：简单解释
- 2. dubbo负载均衡策略
-
- 2.1 Random LoadBalance
- 2.2 RoundRobin LoadBalance
- 2.3 LeastActive LoadBalance
- 2.4 ConsistentHash LoadBalance
- 3. 配置
- 4. 源码
- 参考
前言
在上一篇博客中，介绍了zookeeper作为dubbo的注册中心是如何工作的，有一个很重要的点，我们的程序是分布式应用，服务部署在几个节点（服务器）上，当消费者调用服务时，zk返回给dubbo的是一个节点列表，但是dubbo只会选择一台服务器，那么它究竟会选择哪一台呢？这就是dubbo的负载均衡策略了，本篇博客就来聚焦dubbo的负载均衡策略。
1. 什么是负载均衡
1.1:负载均衡简介
以下是wikipedia对负载均衡的定义：
负载均衡改善了跨多个计算资源（例如计算机，计算机集群，网络链接，中央处理单元或磁盘驱动的的工作负载分布。负载平衡旨在优化资源使用，最大化吞吐量，最小化响应时间，并避免任何单个资源的过载。使用具有负载平衡而不是单个组件的多个组件可以通过冗余提高可靠性和可用性。负载平衡通常涉及专用软件或硬件
1.2：简单解释
这个概念如何理解呢？通俗点来说假如一个请求从客户端发起,比如(查询订单列表)，要选择服务器进行处理，但是我们的集群环境提供了5个服务器ABCDE，每个服务器都有处理这个请求的能力,此时客户端就必须选择一个服务器来进行处理(不存在先选择A，处理一会又选择C,又跳到D).说白了就是一个选择的问题。当请求多了的话，就要考虑各服务器的负载，一共5个服务器，不可能每次都让一个服务器都来处理吧，比如把让其他服务器来分压。这就是负载均衡的优点：避免单个服务器响应同一请求，容易造成服务器宕机、崩溃等问题。
2. dubbo负载均衡策略
如果在消费端和服务端都配置了负载均衡策略，以消费端为准。
2.1 Random LoadBalance
- 随机，按
权重设置随机概率。默认策略 - 在一个截面上碰撞的概率高，但调用量越大分布越均匀，而且按概率使用权重后也比较均匀，有利于动态调整提供者权重。
权重大的, 随机到的概率就大一点, 假如 a权重9, b权重1, 则随机到a的概率是a的权重除以总权重即0.9, b的概率是0.1
2.2 RoundRobin LoadBalance
- 轮询，按公约后的
权重设置轮询比率。 -
存在慢的提供者累积请求的问题，比如：第二台机器很慢，但没挂，当请求调到第二台时就卡在那，久而久之，所有请求都卡在调到第二台上。 解决办法 : 结合权重，把第二台机(性能低的)的权重设置低一点
轮询就是多个服务提供者, 一个一个来执行请求. 假如有abc3个节点提供同一个服务, 其性能比例abc=2:1:1
普通轮询算法: 执行方案可能是 {a,b,c} 加权轮询算法: 配置a的权重是200, b和c的权重是100, 执行方案可能是 {a,a,b,c} 平滑加权轮询算法: 配置a的权重是200, b和c的权重是100, 执行方案可能是 {a,b,a,c}
2.3 LeastActive LoadBalance
- 最少活跃调用数，相同活跃数的随机，活跃数指调用前后计数差。
- 使慢的提供者收到更少请求，因为越慢的提供者的调用前后计数差会越大。
消费者缓存每个服务提供者的信息, 每个服务提供者有一个active字段来代表当前消费者正在调用的线程数, 调用前加1, 调用后减1, 调用时找一个active字段最小的, 说明该服务提供者正被调用中的线程少。
严格来说，这个是局部的统计，即消费者统计自己关心的那些服务提供者，而不是在服务器端统计全局的。好处是减轻服务器压力，并简化统计方式。
我认为这个算法比较好, 一定程度上能够感知到服务端的压力, 动态调整选择的服务提供者。
完整逻辑是这样的： 1.消费者会缓存所调用服务的所有提供者，比如记为p1、p2、p3三个服务提供者，每个提供者内都有一个属性记为active，默认位0 2.消费者在调用次服务时，如果负载均衡策略是leastactive 3.消费者端会判断缓存的所有服务提供者的active，选择最小的，如果都相同，则随机 4.选出某一个服务提供者后，假设位p2，Dubbo就会对p2.active 1 5.然后真正发出请求调用该服务 6.消费端收到响应结果后，对p2.active-1 7.这样就完成了对某个服务提供者当前活跃调用数进行了统计，并且并不影响服务调用的性能
2.4 ConsistentHash LoadBalance
- 一致性 Hash，相同参数的请求总是发到同一提供者。
其实就是路由至同一个key下
- 当某一台提供者挂时，原本发往该提供者的请求，基于虚拟节点，平摊到其它提供者，不会引起剧烈变动。
- 算法参见：http://en.wikipedia.org/wiki/Consistent_hashing
- 缺省只对第一个参数 Hash，如果要修改，请配置 <dubbo:parameter key=“hash.arguments” value=“0,1” />
- 缺省用 160 份虚拟节点，如果要修改，请配置 <dubbo:parameter key=“hash.nodes” value=“320” />
3. 配置
如果在消费端和服务端都配置了负载均衡策略，以消费端为准。
一般在实际项目我们配置权重或负载均衡时不在代码中写死，我们动态使用默认配置，需要调节时通过dubbo管控台上进行配置。
服务端服务级别：
代码语言：javascript复制<dubbo:service interface="..." loadbalance="roundrobin" />服务端方法级别：
代码语言：javascript复制<dubbo:service interface="...">
<dubbo:method name="..." loadbalance="roundrobin"/>
</dubbo:service>客户端服务级别
代码语言：javascript复制<dubbo:reference interface="..." loadbalance="roundrobin" />客户端方法级别：
代码语言：javascript复制<dubbo:reference interface="...">
<dubbo:method name="..." loadbalance="roundrobin"/>
</dubbo:reference>4. 源码
参见下面的《dubbo负载均衡策略》
参考
dubbo负载均衡策略 负载均衡官网配置手册 Dubbo 基础概念 仅看负载均衡章节
发布者：全栈程序员栈长，转载请注明出处：https://javaforall.cn/157458.html原文链接：https://javaforall.cn
