项目方案DUBBO 负载均衡策之略哈希一致的应用

Posted 2023-03-30 伯子南

🥳 作者：伯子南
😎 坚信： 好记性不如乱笔头，独乐乐不如众乐乐
💪 个人主页：https://blog.csdn.net/qq_34577234?spm=1010.2135.3001.5421
👬🏻 觉得博主文章不错的话，可以三连支持一下！如有需要我的支持，请私信！

👀前言

本周新文来啦！本文是结合工作中遇到的问题，对DUBBO负载均衡的学习与应用。希望各位读者大佬能够从中获益，或者给出一些指导意见。

文章目录

• • • 👀前言
    • 👉🏼问题背景与解决思路
    • • 🪒1.项目架构：
      • 🧪2.问题根源：
      • 📯3.问题解决思路：
    • 💻DUBBO 负载均衡
    • 🧲常见内置负载均衡策略
    • • Random
      • RoundRobin
      • LeastActive
      • ShortestResponse
      • ConsistentHash
    • 🩺负载均衡策略配置粒度
    • 🧬应用与问题解决

👉🏼问题背景与解决思路

    先来简单介绍下我们项目的背景：

🪒1.项目架构：

    简单的梳理我们系统的架构如下图所示，分为1个前台应用和多个后台应用：

    前台主机， 作为消费者， 通过DUBBO来访问后台主机。
    为了避免访问压力过大，后台有多台主机供前台访问，前台访问时的负载均衡策略是默认的随机策略。

🧪2.问题根源：

    我们系统是一个偏于流程的应用，在业务数据真正持久化到数据库之前，都是在后台主机内存中的。
    在一次业务流程中，前台多次调用后台服务可能因为随机的负载均衡策略，请求到不同的主机上。
    那么就会出现这样的问题：
    初始化业务数据服务service1是在A主机，使用业务数据请求服务service2可能    访问到了B主机，如果此服务需要获取内存中的业务数据，那么就会访问不到。

📯3.问题解决思路：

     试想，如果service2也能访问到service1所访问的主机，那么问题不就解决了嘛？！
    这意味着，我们就不能再使用随机策略了。应该换一种能够保证同一次业务流程中的服务调用都访问同一台主机的负载均衡策略。

💻DUBBO 负载均衡

     在集群负载均衡时，Dubbo 提供了多种均衡策略，缺省为 random 随机调用。
     具体实现上，Dubbo 提供的是客户端负载均衡，即由 Consumer 通过负载均衡算法得出需要将请求提交到哪个 Provider 实例。

🧲常见内置负载均衡策略

DUBBO内置了如下这些负载均衡算法

算法	特性	备注
RandomLoadBalance	加权随机	默认算法，默认权重相同
RoundRobinLoadBalance	加权轮询	借鉴于 nginx 的平滑加权轮询算法，默认权重相同，
LeastActiveLoadBalance	最少活跃优先 + 加权随机	背后是能者多劳的思想
ShortestResponseLoadBalance	最短响应优先 + 加权随机	更加关注响应速度
ConsistentHashLoadBalance	一致性 Hash	确定的入参，确定的提供者，适用于有状态请求

Random

• 加权随机，按权重设置随机概率。
• 在一个截面上碰撞的概率高，但调用量越大分布越均匀，而且按概率使用权重后也比较均匀，有利于动态调整提供者权重。
• 缺点：存在慢的提供者累积请求的问题，比如：第二台机器很慢，但没挂，当请求调到第二台时就卡在那，久而久之，所有请求都卡在调到第二台上。

RoundRobin

• 加权轮询，按公约后的权重设置轮询比率，循环调用节点
• 缺点：同样存在慢的提供者累积请求的问题。

LeastActive

• 加权最少活跃调用优先，活跃数越低，越优先调用，相同活跃数的进行加权随机。活跃数指调用前后计数差（针对特定提供者：请求发送数 - 响应返回数），表示特定提供者的任务堆积量，活跃数越低，代表该提供者处理能力越强。
• 使慢的提供者收到更少请求，因为越慢的提供者的调用前后计数差会越大；相对的，处理能力越强的节点，处理更多的请求。

ShortestResponse

• 加权最短响应优先，在最近一个滑动窗口中，响应时间越短，越优先调用。相同响应时间的进行加权随机。
• 使得响应时间越快的提供者，处理更多的请求。
• 缺点：可能会造成流量过于集中于高性能节点的问题。

ConsistentHash

• 一致性 Hash，相同参数的请求总是发到同一提供者。
• 当某一台提供者挂时，原本发往该提供者的请求，基于虚拟节点，平摊到其它提供者，不会引起剧烈变动。
• 缺省只对第一个参数 Hash，如果要修改，请配置 <dubbo:parameter key="hash.arguments" value="0,1" />
• 缺省用 160 份虚拟节点，如果要修改，请配置 <dubbo:parameter key="hash.nodes" value="320" />
• 哈希一致性原理的详细解读可以阅读这篇《Dubbo负载均衡策略之 一致性哈希》

🩺负载均衡策略配置粒度

• 服务端 服务级别：

<dubbo:service interface="接口名" loadbalance="策略名称"/>

• 服务端 方法级别：

<dubbo:service interface="接口名">
　　<dubbo:method name="方法名" loadbalance="均衡策略名"/>
</dubbo:service>

• 客户端 服务级别：

<dubbo:reference interface="" loadbalance="均衡策略名" />

• 客户端 方法级别：

<dubbo:reference interface="" loadbalance="均衡策略名">
    <dubbo:method name="方法名" loadbalance="均衡策略名"/>
</dubbo:reference>

🧬应用与问题解决

     很显然，对于解决我们系统中的问题。这里应该使用哈希一致性的复杂均衡策略，来保证同一笔业务流程中，需要使用业务数据的的请求访问到同一台主机上。
     当然，并不是所有的服务请求到需要使用业务数据，那么我们不需要每个dubbo服务都使用哈希一直性策略。
     所以最终的应用方案是，使用哈希一致的负载均衡策略，并且仅仅是配置在个别的流程类方法上。