【Dubbo】负载均衡

最新推荐文章于 2025-03-05 13:52:07 发布

gossipchat

最新推荐文章于 2025-03-05 13:52:07 发布

阅读量349

点赞数

分类专栏： Dubbo

本文链接：https://blog.youkuaiyun.com/HiJamesChen/article/details/113556267

版权

本文介绍了Dubbo的负载均衡模式，包括Random、RoundRobin、LeastActive和ConsistentHash策略，详细解析了各种策略的工作原理和适用场景。此外，还阐述了如何实现自定义的LoadBalance，以满足特定的负载均衡需求。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

一. 概述

版本：2.7.8

解决问题

当有多个服务提供者时，避免请求集中到其中一个或多个，导致负载过高，服务不可用,需要做一定的负载均衡策略。
Dubbo提供了多种均衡策略，默认为random，也就是每次加权随机调用一台服务提供者的服务。

二. Dubbo负载均衡模式

Random LoadBalance：加权随机

按照概率设置权重，比较均匀，并且可以动态调节提供者的权重。

RoundRobin LoadBalance：轮询

轮询，按公约后的权重设置轮询比率。会存在执行比较慢的服务提供者堆积请求的情况，比如一个机器执行得非常慢，但是机器没有宕机（如果宕机了，那么当前机器会从ZooKeeper 的服务列表中删除）。
当很多新的请求到达该机器后，由于之前的请求还没处理完，会导致新的请求被堆积，久而久之，消费者调用这台机器上的所有请求都会被阻塞。

LeastActive LoadBalance：最少活跃调用数

如果每个提供者的活跃数相同，则随机选择一个。
在每个服务提供者里维护着一个活跃数计数器，用来记录当前同时处理请求的个数，也就是并发处理任务的个数。这个值越小，说明当前服务提供者处理的速度越快或者当前机器的负载比较低，所以路由选择时就选择该活跃度最小的机器。
如果一个服务提供者处理速度很慢，由于堆积，同时处理的请求就比较多，也就是说活跃调用数较大，处理速度慢。这时，处理速度慢的提供者将收到更少的请求。

ConsistentHash LoadBalance一致性Hash策略

一致性Hash，可以保证相同参数的请求总是发到同一提供者，当某一台提供者机器宕机时，原本发往该提供者的请求，将基于虚拟节点平摊给其他提供者，这样就不会引起剧烈变动。

三. LoadBalance接口及实现类结构图

在这里插入图片描述

四. 源码解析

1. 接口LoadBalance

负载均衡模式默认为：random

package org.apache.dubbo.rpc.cluster;

@SPI(RandomLoadBalance.NAME)
public interface LoadBalance {
   

    /**
     * select one invoker in list.
     */
    @Adaptive("loadbalance")
    <T> Invoker<T> select(List<Invoker<T>> invokers, URL url, Invocation invocation) throws RpcException;

}

2. AbstractLoadBalance抽象类

使用模板模式执行公共业务
各个实现类实现抽象方法(doSelect)
getWeight：从URL中获取各个服务提供者的权重

package org.apache.dubbo.rpc.cluster.loadbalance;

public abstract class AbstractLoadBalance implements LoadBalance {

   @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);
    }

    protected abstract <T> Invoker<T> doSelect(List<Invoker<T>> invokers, URL url, Invocation invocation);

    /**
     * Get the weight of the invoker's invocation which takes warmup time into account
     * if the uptime is within the warmup time, the weight will be reduce proportionally
     *
     * @param invoker    the invoker
     * @param invocation the invocation of this invoker
     * @return weight
     */
    int getWeight(Invoker&l