dubbo负载均衡算法及源码解析

最新推荐文章于 2022-08-16 13:50:09 发布

csdn_JAVA_HL

最新推荐文章于 2022-08-16 13:50:09 发布

阅读量1.1k

点赞数 1

分类专栏：源码解析文章标签： dubbo 源码一致性hash 算法

本文链接：https://blog.csdn.net/update_java/article/details/80923382

版权

0 篇文章 0 订阅

订阅专栏

dubbo中的负载均衡策略有四种如下：随机（Random）、轮询（RoundRobin）、最少活跃调用数(LeastActive)、一致性Hash(ConsistentHash)，缺省配置默认为 Random 随机负载均衡策略

虚拟圆环：一致性哈希将整个哈希值空间组织成一个虚拟的圆环。如假设某哈希函数的值空间为0~2^32 -1(即：哈希值为一个32位无符号整形)，
整个空间按照顺时针方向组织，0和2^32 -1在零点出重合。
映射服务器到虚拟圆环（虚拟）节点：将所有服务器使用指定Hash函数计算Hash值，并且映射到虚拟圆环的对应位置，即：服务对应的节点；
定位数据访问的服务器：将数据key使用相同的Hash函数计算出Hash值，并确定此数据在Hash环上的位置，从此位置沿环顺时针寻找到的第一个服务器
节点，即为当前数据key要访问的服务器。
服务器使用虚拟节点的目的：可以保证在服务器数量变动的情况下，仍然使得资源能够均匀分布（即：负载均衡）。
KETAMA_HASH算法的好处：解决Hash值分布不均的问题。
经常使用TreeMap来表示Hash环的原因：用TreeMap的时间复杂度是O(logN)，相对效率比较高，且TreeMap使用了红黑树结构存储实体对象。

一致性哈希算法常用于负载均衡中要求资源被均匀的分布到所有节点上，并且对资源的请求能快速路由到对应的节点上.
相比普通的哈希算法采用简单取模的方式，将缓存服务器进行散列；一致性哈希算法能有效降低服务器个数变化对整体缓存的影响。
MemCache集群，要求存储各种数据均匀的存到集群中的各个节点上，访问这些数据时能快速的路由到集群中对应存放该数据的节点上；
并且要求增删集群中节点对整个集群的影响很小，不至于有大的动荡造成整体负载的不稳定；
RPC过程中服务提供者做N个节点的集群部署，为了能在服务上维护一些业务状态，希望同一种请求每次都落到同一台服务上。

一致性Hash负载均衡算法，相同参数的请求总是发送到同一个服务提供者（在服务提供者列表不变的前提下）
当某一台提供者挂掉时，原本发往该提供者的请求，将基于虚拟节点，平摊到其他的提供者，不会引起剧烈变动。
默认情况下，一致性Hash会使用 160个虚拟节点 构造一致性Hash环，并且只使用对应 方法第一个参数 的Hash值作为
key去Hash环上获取对应的服务提供者对象（Invoker），改变默认配置方式如下：<dubbo:parameter key="hash.arguments" value="0,1" />
<dubbo:parameter key="hash.nodes" value="320" />

ConcurrentMap<String, ConsistentHashSelector<?>> selectors 用于存储每个请求url（由dubbo配置中的interface+group+versi
on+methodName组装而成）与一致性Hash对象ConsistentHashSelector<T>（由服务提供者列表，相当于服务器列表构造而成）的Map映射（一致性
Hash对象的构成具体见2）
构造一致性Hash环时的重要属性：TreeMap<Long, Invoker<T>> virtualInvokers 用于存储一致性Hash对象环上的虚拟节点，每个节点存储
提供者url的Hash值 与 服务提供者对象(Invoker)的对应关系
获取服务提供者步骤：1、通过请求url获取对应的一致性Hash对象；2、通过请求参数的Hash值在一致性hash环上面查找对应的虚拟节点，获取服务提
供者;此处利用了TreeMap.tailMap(key)返回其键大于或等于 fromKey 的Map集合的特性。
算法的具体实现以及源码完整注解见ConsistentHashLoadBalance类

int active = RpcStatus.getStatus(invoker.getUrl(),invocation.getMethodName()).getActive(); // 活跃数 获取当前服务提供者url+method对应的active数量。 RpcStatus 通过一个ConcurrentMap<String, ConcurrentMap<String, RpcStatus>> METHOD_STATISTICS 记录所有的服务提供者每个服务（用url+mothod 标识）的的RpcStatus，其中包括active（活跃数）、total(处理请求的总数)、failed(请求失败数量)、以及各种情况的服务处理时间。
dubbo是如何记录服务提供者各个服务url的active数量呢？
- 通过Filter（ActiveLimitFilter（对应消费者）和ExecuteLimitFilter（对应提供者））对active进行更新新操作，当某个provider某个服务被分配到请求，这两个Filter都会在服务提供者处理请求之前将 avtive 属性进行加一操作，并且在请求处理完成或者异常时将avtive属性进行减一操作。