Dubbo--负载均衡流程与源码分析(上)

前文

上一篇讲到了Dubbo集群调用流程,主要包括路由、负载均衡、容错等等。

那么今天就讲讲负载均衡。

Dubbo版本(2.7.x)

为啥要有负载均衡

每台机器因为硬件、网络等原因性能肯定不同,就算是相同性能的机器,如果每次调用都只是相同一台,资源浪费不说,还可能因为相同调用机器满负荷而导致接口不稳定。因此可以根据每台机器性能可以灵活选择不同的提供者,负载均衡孕育而生。

策略

LoadBalance

RandomLoadBalance

  • 随机,按权重设置随机概率。

  • 在一个截面上碰撞的概率高,但调用量越大分布越均匀,而且按概率使用权重后也比较均匀,有利于动态调整提供者权重。

RoundRobinLoadBalance

  • 轮询,按公约后的权重设置轮询比率。

  • 存在慢的提供者累积请求的问题,比如:第二台机器很慢,但没挂,当请求调到第二台时就卡在那,久而久之,所有请求都卡在调到第二台上。

LeastActiveLoadBalance

  • 最少活跃调用数,相同活跃数的随机,活跃数指调用前后计数差。

  • 使慢的提供者收到更少请求,因为越慢的提供者的调用前后计数差会越大。

ConsistentHashLoadBalance

  • 一致性 Hash,相同参数的请求总是发到同一提供者。

  • 当某一台提供者挂时,原本发往该提供者的请求,基于虚拟节点,平摊到其它提供者,不会引起剧烈变动。

ShortestResponseLoadBalance

  • 最短响应时间负载均衡

  • 选出响应时间最短的,如果只有一个则直接调用,否则根据权重比例进行调用,若权重相同则随机调用。

源码分析

AbstractLoadBalance#select

父类定义主流程,子类通过实现具体的doSelect方法来进行扩展。
父类定义主流程,子类通过实现具体的doSelect方法来进行扩展。

@Override
public <T> Invoker<T> select(List<Invoker<T>> invokers, URL url, Invocation invocation) {
    //判空
    if (CollectionUtils.isEmpty(invokers)) {
        return null;
    }
    //只有一个则直接返回,用啥策略都白搭
    if (invokers.size() == 1) {
        return invokers.get(0);
    }
    //扩展点
    return doSelect(invokers, url, invocation);
}

Random

通过权重来进行随机,如果全部提供者的权重都相等,则随机选择。

举个例子,下面有三个服务提供者

A:weight=10
B:weight=15
C:weight=25

0____________10________________________25_____________________________________50

​     A                   B                                   C

接着使用random函数在[0,50)中选择一个随机数,在哪个范围则使用哪个提供者。

如果权值都相等的情况下,则直接在0到服务提供者总数-1进行随机,直接通过数组get相应坐标。


RandomLoadBalance#doSelect

**

@Override
protected <T> Invoker<T> doSelect(List<Invoker<T>> invokers, URL url, Invocation invocation) {
    // 服务者总数
    int length = invokers.size();
    // 每个服务者权重相等,则这个标志为true,后面会进行判断
    boolean sameWeight = true;
    // 记录每个服务者的权重
    int[] weights = new int[length];
    // 记录第一个服务者的权重,为什么不放在循环中?方便sameWeight标志的判断
    // 并且之前判断过总数,因此服务者数量必定大于等于2
    int firstWeight = getWeight(invokers.get(0), invocation);
    weights[0] = firstWeight;
    // 权重总和目的后续权重不同时进行随机选取使用
    int totalWeight = firstWeight;
    for (int i = 1; i < length; i++) {
        int weight = getWeight(invokers.get(i), invocation);
        // 进行记录
        weights[i] = weight;
        // 累加
        totalWeight += weight;
        if (sameWeight && weight != firstWeight) {
            sameWeight = false;
        }
    }
    //如果每个服务者权重不相同且总权重大于0,则利用总权重进行随机
    if (totalWeight > 0 && !sameWeight) {
        //权重中获取随机数,0<=offset<totalWeight
        int offset = ThreadLocalRandom.current().nextInt(totalWeight);
        //进行相减,若小于0,说明在第i个权重区间
        for (int i = 0; i < length; i++) {
            offset -= weights[i];
            if (offset < 0) {
                return invokers.get(i);
            }
        }
    }
    //总权重为0或每个服务者权值相等,则根据数组长度随机获取
    return invokers.get(ThreadLocalRandom.current().nextInt(length));
}

RoundRobin

讲一下Dubbo中的加权轮询算法是如何实现的。

首先定义一个类。记录相应的元数据:设置的权值,当前权值,总权值。

public class WeightedRoundRobin {
    //当前的权值
    private int curWeight;
    //设置得权值
    private int weight;
    //服务提供者总权值
    private int totalWeight;
}

有三个服务提供者A、B、C,权重比为5:2:1。进行8次调用。

首先进行初始化,初始化时curWeight和weigth相等。

接着每次进行判断,看谁的curWeight最大则调用谁,同时调用者的curWeight=curWeight-totalWeight,最后每个提供者的curWeight=curWeight+weight。

下图为计算流程。

轮询流程

八次调用后的计算逻辑图如下:

A B C 调用者
[5,5,8] [2,2,8] [1,1,8]
[3,5,8] [4,2,8] [2,1,8] A
[8,5,8] [-2,2,8] [3,1,8] B
[5,5,8] [0,2,8] [4,1,8] A
[2,5,8] [2,2,8] [5,1,8] A
[7,5,8] [4,2,8] [-2,1,8] C
[4,5,8] [6,2,8] [-1,1,8] A
[1,5,8] [0,2,8] [0,1,8] B
[2,5,8] [2,2,8] [1,1,8] A

可以看到8此调用后,A调用5次,B调用2次,C调用1次。的确是加权轮询并且十分平滑。

RoundRobinLoadBalance#doSelect

实现中比上述多了一步,如果一段时间内没有访问,则会重置,重新进行轮询。

@Override
protected <T> Invoker<T> doSelect(List<Invoker<T>> invokers, URL url, Invocation invocation) {
    //key标志一个方法{group}/{interfaceName}:{version}.{methodName}
    String key = invokers.get(0).getUrl().getServiceKey() + "." + invocation.getMethodName();
    //value->map{key:invoker的唯一标志 value:轮询权重相关类WeightedRoundRobin}
    //methodWeightMap的value就是不同的invokers,如果为空则创建一个空的map
    ConcurrentMap<String, WeightedRoundRobin> map = methodWeightMap.computeIfAbsent(key, k -> new ConcurrentHashMap<>());
    //总权重
    int totalWeight = 0;
    //当前最大权值
    long maxCurrent = Long.MIN_VALUE;
    //当前时间
    long now = System.currentTimeMillis();
    //被选中的调用者
    Invoker<T> selectedInvoker = null;
    //被选中调用者所对应的权值类
    WeightedRoundRobin selectedWRR = null;
    //进行循环
    for (Invoker<T> invoker : invokers) {
        //获取获取invoker的唯一标志
        String identifyString = invoker.getUrl().toIdentityString();
        //获取对应的权值
        int weight = getWeight(invoker, invocation);
        //如果缓存内没有则进行创建
        WeightedRoundRobin weightedRoundRobin = map.computeIfAbsent(identifyString, k -> {
            WeightedRoundRobin wrr = new WeightedRoundRobin();
            wrr.setWeight(weight);
            return wrr;
        });
        //如果url中的权值更新,则更新缓存中权值
        if (weight != weightedRoundRobin.getWeight()) {
            //weight changed
            weightedRoundRobin.setWeight(weight);
        }
        //当前权值=当前权值+设置的权值
        //目的是获取最大的当前权值的提供者 作为调用使用
        long cur = weightedRoundRobin.increaseCurrent();
        //更新更新时间
        weightedRoundRobin.setLastUpdate(now);
        //获取全部中invoker中有效权值最大的那个提供者
        if (cur > maxCurrent) {
            maxCurrent = cur;
            selectedInvoker = invoker;
            selectedWRR = weightedRoundRobin;
        }
        //总权值累加,目的是将selectedWRR中的有效权值进行相减方便后续加权轮询
        totalWeight += weight;
    }
    //一段时间内没有访问,则去掉缓存中的记录重新计算
    if (invokers.size() != map.size()) {
        map.entrySet().removeIf(item -> now - item.getValue().getLastUpdate() > RECYCLE_PERIOD);
    }
    if (selectedInvoker != null) {
        selectedWRR.sel(totalWeight);
        return selectedInvoker;
    }
    // should not happen here
    return invokers.get(0);
}
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 218,204评论 6 506
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 93,091评论 3 395
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 164,548评论 0 354
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 58,657评论 1 293
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 67,689评论 6 392
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 51,554评论 1 305
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 40,302评论 3 418
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 39,216评论 0 276
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 45,661评论 1 314
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 37,851评论 3 336
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 39,977评论 1 348
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 35,697评论 5 347
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 41,306评论 3 330
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 31,898评论 0 22
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 33,019评论 1 270
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 48,138评论 3 370
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 44,927评论 2 355

推荐阅读更多精彩内容