一致性hash算法

最新推荐文章于 2024-07-10 11:04:17 发布

127.0.0.0:8848

最新推荐文章于 2024-07-10 11:04:17 发布

阅读量137

点赞数

分类专栏：算法文章标签：哈希算法算法散列表

本文链接：https://blog.csdn.net/qq_46134095/article/details/125652927

版权

算法专栏收录该内容

1 篇文章 0 订阅

订阅专栏

计算hash

首先我们说一下hash。现在有三台redis服务器，A,B,C。如果现在有个key为abc。我们通过hash算法，取余得到放在哪个服务器。
但是这样有个问题，就是如果我们对服务器进行了扩容，我们在计算这个key为abc的，就有问题，我们得到的结果很可能不是之前的结果。这样会导致请求的缓存穿透，大量的请求落到数据库上了，那么我们使用缓存的目的就没有达到。

一致性哈希

一致性hash的处理逻辑

一致性hash算法会建立一个有2^ 32个槽点(0 - 2^ 32-1) 的hash环，假设现在有A、B、C三台服务器，以A为栗，会进行hash(A)%2^ 32，得到一个0 - 2^32-1之间的数，然后映射到hash环上，如图所示
在这里插入图片描述

接着，对要查询的 key-01 进行哈希计算，确定此 key-01 映射在哈希环的位置，然后从这个位置往顺时针的方向找到第一个节点，就是存储该 key-01 数据的节点。

比如，下图中的 key-01 映射的位置，往顺时针的方向找到第一个节点就是节点 A。所以，当需要对指定 key 的值进行读写的时候，要通过下面 2 步进行寻址：

对 key 进行哈希计算，确定此 key 在环上的位置；
从这个位置沿着顺时针方向走，遇到的第一节点就是存储 key 的节点。

key-02,key-03 都是这样操作的，如图所示
在这里插入图片描述

当节点发生的数目发生了改变

【情况1】假设节点数量从 3 增加到了 4，新的节点 D 经过哈希计算后映射到了下图中的位置：
在这里插入图片描述
可以看到，key-01、key-03 都不受影响，只有 key-02 需要被迁移节点 D。

【情况2】假设节点数量从 3 减少到了 2，比如将节点 A 移除：
在这里插入图片描述
可以看到，key-02 和 key-03 不会受到影响，只有 key-01 需要被迁移节点 B。

因此，在一致哈希算法中，如果增加或者移除一个节点，仅影响该节点在哈希环上顺时针相邻的后继节点，其它数据也不会受到影响。

hash倾斜

上面这些图中 3 个节点映射在哈希环还是比较分散的，所以看起来请求都会「均衡」到每个节点。
但是一致性哈希算法并不保证节点能够在哈希环上分布均匀，这样就会带来一个问题，会有大量的请求集中在一个节点上。
在这里插入图片描述
这时候有一半以上的数据的寻址都会找节点 A，也就是访问请求主要集中的节点 A 上，这肯定不行的呀，说好的负载均衡呢，这种情况一点都不均衡。

另外，在这种节点分布不均匀的情况下，进行容灾与扩容时，哈希环上的相邻节点容易受到过大影响，容易发生雪崩式的连锁反应。

比如，上图中如果节点 A 被移除了，当节点 A 宕机后，根据一致性哈希算法的规则，其上数据应该全部迁移到相邻的节点 B 上，这样，节点 B 的数据量、访问量都会迅速增加很多倍，一旦新增的压力超过了节点 B 的处理能力上限，就会导致节点 B 崩溃，进而形成雪崩式的连锁反应。

所以，一致性哈希算法虽然减少了数据迁移量，但是存在节点分布不均匀的问题。

解决hash倾斜

要想解决节点能在哈希环上分配不均匀的问题，就是要有大量的节点，节点数越多，哈希环上的节点分布的就越均匀。简单来说就是加机器。

但问题是，实际中我们没有那么多节点。所以这个时候我们就加入虚拟节点，也就是对一个真实节点做多个副本。

具体做法是，不再将真实节点映射到哈希环上，而是将虚拟节点映射到哈希环上，并将虚拟节点映射到实际节点，所以这里有「两层」映射关系。

比如对每个节点分别设置 3 个虚拟节点：

对节点 A 加上编号来作为虚拟节点：A-01、A-02、A-03
对节点 B 加上编号来作为虚拟节点：B-01、B-02、B-03
对节点 C 加上编号来作为虚拟节点：C-01、C-02、C-03
引入虚拟节点后，原本哈希环上只有 3 个节点的情况，就会变成有 9 个虚拟节点映射到哈希环上，哈希环上的节点数量多了 3 倍。
在这里插入图片描述
你可以看到，节点数量多了后，节点在哈希环上的分布就相对均匀了。这时候，如果有访问请求寻址到「A-01」这个虚拟节点，接着再通过「A-01」虚拟节点找到真实节点 A，这样请求就能访问到真实节点 A 了。