一文搞懂一致性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参考模型
1043 1
信管知识梳理(二)常规信息系统集成技术
|
Kubernetes Linux Docker
【kubernetes】修复 linux 服务器重启后,kubelet 启动失败的问题
【kubernetes】修复 linux 服务器重启后,kubelet 启动失败的问题
3340 1
|
Python Windows
Win10安装Python3.9
Win10安装Python3.9
1988 0
|
5月前
|
设计模式 消息中间件 监控
并发设计模式实战系列(17):信号量(Semaphore)
🌟 大家好,我是摘星! 🌟今天为大家带来的是并发设计模式实战系列,第十六章信号量(Semaphore),废话不多说直接开始~
138 10
|
7月前
|
数据采集 算法 数据安全/隐私保护
【硬件测试】基于FPGA的16QAM调制+软解调系统开发与硬件片内测试,包含信道模块,误码统计模块,可设置SNR
本文基于之前开发的16QAM调制与软解调系统,增加了硬件测试功能。该系统包含FPGA实现的16QAM调制、软解调、高斯信道、误码率统计模块,并新增了ILA在线数据采集和VIO在线SNR设置模块。通过硬件测试,验证了不同SNR条件下的系统性能。16QAM软解调通过比较接收信号采样值与16个调制点的距离,选择最近的调制点来恢复原始数据。核心Verilog代码实现了整个系统的功能,包括SNR设置、信号处理及误码率统计。硬件测试结果表明系统在不同SNR下表现良好,详细操作步骤可参考配套视频。
169 13
|
12月前
|
安全 网络安全
Kali渗透测试:使用Armitage扫描网络
Kali渗透测试:使用Armitage扫描网络
207 3
|
存储 安全 数据安全/隐私保护
ERP系统的灾备与数据恢复:保障企业业务连续性
【7月更文挑战第29天】 ERP系统的灾备与数据恢复:保障企业业务连续性
559 2
|
12月前
|
存储 消息中间件 缓存
Redis 简介
10月更文挑战第14天
292 58
|
10月前
|
存储 应用服务中间件 nginx
Nginx限流怎么做
Nginx 通过 limit_req 模块实现限流,保护后端服务器。配置示例中,定义了限流区域 `limit`,每秒允许 10 个请求,客户端 IP 超过限流后允许 20 个突发请求,超出则立即返回 503 错误。
247 6
|
开发者
请谨慎使用 @Builder 注解!
本文主要指出 @Builder 存在的一些问题,指出它并不是链式编程的最佳实践。
1277 54