每日一博 | 一文搞懂一致性 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
先说说实现的原理:
- 计算
key
的hash - 找到第一个匹配的
virtual node
的 index,并取到对应的h.keys[index]
:virtual node hash 值 - 对应到这个
ring
中去寻找一个与之匹配的actual node
其实我们可以看到 ring
中获取到的是一个 []node
。这是因为在计算 virtual node hash
,可能会发生hash冲突,不同的 virtual node hash
对应到一个实际node。
这也说明:node
与 virtual node
是一对多的关系。而里面的 ring
就是下面这个设计:
这个其实也就表明了一致性hash的分配策略:
virtual node
作为值域划分。key
去获取node
,从划分依据上是以virtual node
作为边界virtual node
通过hash
,在对应关系上保证了不同的 node 分配的key是大致均匀的。也就是 打散绑定- 加入一个新的 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可以广泛使用在分布式系统中:
- 分布式缓存。可以在
redis cluster
这种存储系统上构建一个cache proxy
,自由控制路由。而这个路由规则就可以使用一致性hash算法 - 服务发现
- 分布式调度任务
以上这些分布式系统中,都可以在负载均衡模块中使用。
项目地址
https://github.com/tal-tech/go-zero
欢迎使用 go-zero 并 star 支持我们!
微信交流群
关注『微服务实践』公众号并点击 交流群 获取社区群二维码。
一致性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
先说说实现的原理:
- 计算
key
的hash - 找到第一个匹配的
virtual node
的 index,并取到对应的h.keys[index]
:virtual node hash 值 - 对应到这个
ring
中去寻找一个与之匹配的actual node
其实我们可以看到 ring
中获取到的是一个 []node
。这是因为在计算 virtual node hash
,可能会发生hash冲突,不同的 virtual node hash
对应到一个实际node。
这也说明:node
与 virtual node
是一对多的关系。而里面的 ring
就是下面这个设计:
这个其实也就表明了一致性hash的分配策略:
virtual node
作为值域划分。key
去获取node
,从划分依据上是以virtual node
作为边界virtual node
通过hash
,在对应关系上保证了不同的 node 分配的key是大致均匀的。也就是 打散绑定- 加入一个新的 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可以广泛使用在分布式系统中:
- 分布式缓存。可以在
redis cluster
这种存储系统上构建一个cache proxy
,自由控制路由。而这个路由规则就可以使用一致性hash算法 - 服务发现
- 分布式调度任务
以上这些分布式系统中,都可以在负载均衡模块中使用。
项目地址
https://github.com/tal-tech/go-zero
https://gitee.com/kevwan/go-zero
欢迎使用 go-zero 并 star 支持我们!
微信交流群
关注『微服务实践』公众号并点击 交流群 获取社区群二维码。

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
-
上一篇
Gorse —— Go 推荐系统引擎
Gorse 是一个用 Go 编写的开源推荐系统。Gorse 旨在成为一个通用的开源推荐系统,可以快速引入各种在线服务。通过将物品、用户和交互数据导入 Gorse,系统将自动训练模型为每个用户生成推荐。项目特点如下。 AutoML:通过后台模型搜索自动选择最佳推荐模型和策略。 分布式推荐:单节点训练,分布式预测,在推荐阶段能够实现横向扩展。 RESTful API:为数据 CRUD 和推荐请求提供 RESTful API。 Dashboard:提供数据导入导出、监控、集群状态检查的仪表盘。 Gorse 是一个单节点训练和分布式预测推荐系统。Gorse 将数据存储在 MySQL 或 MongoDB 中,中间数据缓存在 Redis 中。 集群由一个主节点、多个工作节点和服务器节点组成。 主节点负责模型训练、非个性化物品推荐、配置管理、会员管理。 服务器节点负责公开 RESTful API 和在线实时推荐。 工作节点负责为每个用户提供离线推荐。 此外,管理员可以通过主节点的仪表盘进行系统监控、数据导入导出、系统状态检查。
-
下一篇
Intel 开始为 Linux 提供 Thunder Bay SoC 支持
本周,Intel 给 Linux 提交了Thunder BaySoC 系列补丁,以提供相关支持。 该补丁集提供了对 Intel 新的代号为 Thunder Bay 的 Movidius SoC 的初步支持,该 SoC 结合了一个 ARM Cortex A53 CPU 和 Intel Movidius VPU。不过,该补丁集只启用了使 Thunder Bay 全配置或基本配置板启动到 initramfs 所需的最小组件。Movidius VPU 主要用于深度学习和视觉处理任务,能够高效地支持要求苛刻的计算机视觉和边缘 AI 工作负载。 据补丁描述,Thunder Bay 全配置板有 4 个集群,每个集群有 4 个 ARM Cortex A53 CPU、4 个 VPU 处理器和 8GB+8GB+4GB+4GB 的 DDR 内存。而 Thunder Bay 基本配置板同样有 4 个集群,不过每个集群仅有 4 个 ARM Cortex A53 CPU、2 个 VPU 处理器以及 8GB+4GB DDR内存。此外,该补丁集还包含了对 Thunder Bay 的 eMMC PHY 和 Design...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- Docker快速安装Oracle11G,搭建oracle11g学习环境
- SpringBoot2配置默认Tomcat设置,开启更多高级功能
- Springboot2将连接池hikari替换为druid,体验最强大的数据库连接池
- SpringBoot2整合MyBatis,连接MySql数据库做增删改查操作
- SpringBoot2编写第一个Controller,响应你的http请求并返回结果
- SpringBoot2初体验,简单认识spring boot2并且搭建基础工程
- CentOS7编译安装Cmake3.16.3,解决mysql等软件编译问题
- MySQL8.0.19开启GTID主从同步CentOS8
- Docker使用Oracle官方镜像安装(12C,18C,19C)
- Jdk安装(Linux,MacOS,Windows),包含三大操作系统的最全安装