一文搞懂一致性hash的原理和实现

简介: 一文搞懂一致性hash的原理和实现

在 go-zero 的分布式缓存系统分享里,Kevin 重点讲到过一致性hash的原理和分布式缓存中的实践。本文来详细讲讲一致性hash的原理和在 go-zero 中的实现。

以存储为例,在整个微服务系统中,我们的存储不可能说只是一个单节点。

  • 一是为了提高稳定,单节点宕机情况下,整个存储就面临服务不可用;
  • 二是数据容错,同样单节点数据物理损毁,而多节点情况下,节点有备份,除非互为备份的节点同时损毁。

那么问题来了,多节点情况下,数据应该写入哪个节点呢?

hash

所以本质来讲:我们需要一个可以将输入值“压缩”并转成更小的值,这个值通常状况下是唯一、格式极其紧凑的,比如uint64

  • 幂等:每次用同一个值去计算 hash 必须保证都能得到同一个值

这个就是 hash 算法完成的。

但是采取普通的 hash 算法进行路由,如:key % N 。有一个节点由于异常退出了集群或者是心跳异常,这时再进行 hash route ,会造成大量的数据重新 分发到不同的节点 。节点在接受新的请求时候,需要重新处理获取数据的逻辑:如果是在缓存中,容易引起 缓存雪崩

此时就需要引入 consistent hash 算法了。

consistent hash

我们来看看 consistent hash 是怎么解决这些问题的:

rehash

先解决大量 rehash 的问题:

如上图,当加入一个新的节点时,影响的key只有 key31,新加入(剔除)节点后,只会影响该节点附近的数据。其他节点的数据不会收到影响,从而解决了节点变化的问题。

这个正是:单调性。这也是 normal hash 算法无法满足分布式场景的原因。

数据倾斜

其实上图可以看出:目前多数的key都集中在 node 1 上。如果当 node 数量比较少的情况下,可能引发多数 key 集中在某个 node 上,监控时发现的问题就是:节点之间负载不均。

为了解决这个问题,consistent hash 引入了 virtual node 的概念。

既然是负载不均,我们就人为地构造一个均衡的场景出来,但是实际 node 只有这么多。所以就使用 virtual node 划分区域,而实际服务的节点依然是之前的 node。

具体实现

先来看看 Get()

Get

先说说实现的原理:

  1. 计算 key 的hash
  2. 找到第一个匹配的 virtual node 的 index,并取到对应的 h.keys[index] :virtual node hash 值
  3. 对应到这个 ring 中去寻找一个与之匹配的 actual node

其实我们可以看到 ring 中获取到的是一个 []node 。这是因为在计算 virtual node hash ,可能会发生hash冲突,不同的 virtual node hash 对应到一个实际node。

这也说明:nodevirtual node 是一对多的关系。而里面的 ring 就是下面这个设计:

这个其实也就表明了一致性hash的分配策略:

  1. virtual node 作为值域划分。key 去获取 node ,从划分依据上是以 virtual node 作为边界
  2. virtual node 通过 hash ,在对应关系上保证了不同的 node 分配的key是大致均匀的。也就是 打散绑定
  3. 加入一个新的 node,会对应分配多个 virtual node。新节点可以负载多个原有节点的压力,从全局看,较容易实现扩容时的负载均衡。

Add Node

看完 Get 其实大致就知道整个一致性hash的设计:

type ConsistentHash struct {
  hashFunc Func       // hash 函数
  replicas int       // 虚拟节点放大因子
  keys     []uint64     // 存储虚拟节点hash
  ring     map[uint64][]interface{}     // 虚拟节点与实际node的对应关系
  nodes    map[string]lang.PlaceholderType // 实际节点存储【便于快速查找,所以使用map】
  lock     sync.RWMutex
}

好了这样,基本的一个一致性hash就实现完备了。

具体代码:https://github.com/tal-tech/go-zero/blob/master/core/hash/consistenthash.go

使用场景

开头其实就说了,一致性hash可以广泛使用在分布式系统中:

  1. 分布式缓存。可以在 redis cluster 这种存储系统上构建一个 cache proxy,自由控制路由。而这个路由规则就可以使用一致性hash算法
  2. 服务发现
  3. 分布式调度任务

以上这些分布式系统中,都可以在负载均衡模块中使用。

项目地址

https://github.com/tal-tech/go-zero

相关文章
|
存储 网络协议 中间件
信管知识梳理(二)常规信息系统集成技术
国际标准化组织(ISO)提出的网络体系结构模型,也叫做开发系统互连参考模型(OSI/RM),通常叫做OSI参考模型
1295 1
信管知识梳理(二)常规信息系统集成技术
|
存储 缓存 算法
[转]分布式唯一ID生成方案
分布式唯一ID生成方案
708 0
[转]分布式唯一ID生成方案
|
5月前
|
人工智能 Java API
Java 正式进入 Agentic AI 时代:Spring AI Alibaba 1.1 发布背后的技术演进
Spring AI Alibaba 1.1 正式发布,提供极简方式构建企业级AI智能体。基于ReactAgent核心,支持多智能体协作、上下文工程与生产级管控,助力开发者快速打造可靠、可扩展的智能应用。
4294 43
|
Python Windows
Win10安装Python3.9
Win10安装Python3.9
2368 0
|
消息中间件 监控 供应链
深度剖析 RocketMQ 事务消息!
本文深入探讨了 RocketMQ 的事务消息原理及其应用场景。通过详细的源码分析,阐述了事务消息的基本流程,包括准备阶段、提交阶段及补偿机制。文章还提供了示例代码,帮助读者更好地理解整个过程。此外,还讨论了事务消息的优缺点、适用场景及注意事项,如确保本地事务的幂等性、合理设置超时时间等。尽管事务消息增加了系统复杂性,但在需要保证消息一致性的场景中,它仍是一种高效的解决方案。
1309 2
|
Java 数据库连接 Maven
最新版 | SpringBoot3如何自定义starter(面试常考)
在Spring Boot中,starter是一种特殊的依赖,帮助开发人员快速引入和配置特定功能模块。自定义starter可以封装一组特定功能的依赖和配置,简化项目中的功能引入。其主要优点包括模块化、简化配置、提高代码复用性和实现特定功能。常见的应用场景有短信发送模块、AOP日志切面、分布式ID生成等。通过创建autoconfigure和starter两个Maven工程,并编写自动配置类及必要的配置文件,可以实现一个自定义starter。最后在测试项目中验证其有效性。这种方式使开发者能够更便捷地管理和维护代码,提升开发效率。
2081 1
最新版 | SpringBoot3如何自定义starter(面试常考)
|
10月前
|
缓存 人工智能 负载均衡
PAI 重磅发布模型权重服务,大幅降低模型推理冷启动与扩容时长
阿里云人工智能平台PAI 平台推出模型权重服务,通过分布式缓存架构、RDMA高速传输、智能分片等技术,显著提升大语言模型部署效率,解决模型加载耗时过长的业界难题。实测显示,Qwen3-32B冷启动时间从953秒降至82秒(降幅91.4%),扩容时间缩短98.2%。
|
安全 网络安全
Kali渗透测试:使用Armitage扫描网络
Kali渗透测试:使用Armitage扫描网络
296 3
|
11月前
|
设计模式 消息中间件 监控
并发设计模式实战系列(17):信号量(Semaphore)
🌟 大家好,我是摘星! 🌟今天为大家带来的是并发设计模式实战系列,第十六章信号量(Semaphore),废话不多说直接开始~
310 10
|
数据采集 算法 数据安全/隐私保护
【硬件测试】基于FPGA的16QAM调制+软解调系统开发与硬件片内测试,包含信道模块,误码统计模块,可设置SNR
本文基于之前开发的16QAM调制与软解调系统,增加了硬件测试功能。该系统包含FPGA实现的16QAM调制、软解调、高斯信道、误码率统计模块,并新增了ILA在线数据采集和VIO在线SNR设置模块。通过硬件测试,验证了不同SNR条件下的系统性能。16QAM软解调通过比较接收信号采样值与16个调制点的距离,选择最近的调制点来恢复原始数据。核心Verilog代码实现了整个系统的功能,包括SNR设置、信号处理及误码率统计。硬件测试结果表明系统在不同SNR下表现良好,详细操作步骤可参考配套视频。
334 13

热门文章

最新文章