转载

漫画算法:什么是一致性哈希算法?

file
file
file
file

一年之前——

file
file

未来两年内,系统预估的总订单数量可达一亿条左右。

按Mysql单表存储500万条记录来算,暂时不必分库,单库30个分表是比较合适的水平分表方案。

于是小灰设计了这样的分表逻辑:

  1. 订单表创建单库30个分表
  2. 对用户ID和30进行取模,取模结果决定了记录存于第几个分表
  3. 查询时需要以用户ID作为条件,根据取模结果确定查询哪一个分表

分表方式如下图(为了便于描述,简化为5个分表):

file

过了两个月——

file
file

又过了半年多——

file
file
file
file
file
file
file

小灰的回忆告一段落——

file
file
file
file
file
file

1.首先,我们把全量的缓存空间当做一个环形存储结构。环形空间总共分成2^32个缓存区,在Redis中则是把缓存key分配到16384个slot。

file

2.每一个缓存key都可以通过Hash算法转化为一个32位的二进制数,也就对应着环形空间的某一个缓存区。我们把所有的缓存key映射到环形空间的不同位置。

file

3.我们的每一个缓存节点(Shard)也遵循同样的Hash算法,比如利用IP做Hash,映射到环形空间当中。

file

4.如何让key和节点对应起来呢?很简单,每一个key的顺时针方向最近节点,就是key所归属的存储节点。所以图中key1存储于node1,key2,key3存储于node2,key4存储于node3。

file
file
file

1.增加节点

当缓存集群的节点有所增加的时候,整个环形空间的映射仍然会保持一致性哈希的顺时针规则,所以有一小部分key的归属会受到影响。

file

有哪些key会受到影响呢?图中加入了新节点node4,处于node1和node2之间,按照顺时针规则,从node1到node4之间的缓存不再归属于node2,而是归属于新节点node4。因此受影响的key只有key2。

file

最终把key2的缓存数据从node2迁移到node4,就形成了新的符合一致性哈希规则的缓存结构。

2.删除节点

当缓存集群的节点需要删除的时候(比如节点挂掉),整个环形空间的映射同样会保持一致性哈希的顺时针规则,同样有一小部分key的归属会受到影响。

file

有哪些key会受到影响呢?图中删除了原节点node3,按照顺时针规则,原本node3所拥有的缓存数据就需要“托付”给node3的顺时针后继节点node1。因此受影响的key只有key4。

file

最终把key4的缓存数据从node3迁移到node1,就形成了新的符合一致性哈希规则的缓存结构。

file
file
file
file
file
file
file
file

如上图所示,假如node1的ip是192.168.1.109,那么原node1节点在环形空间的位置就是hash(“192.168.1.109”)。

我们基于node1构建两个虚拟节点,node1-1 和 node1-2,虚拟节点在环形空间的位置可以利用(IP+后缀)计算,例如:
hash(“192.168.1.109#1”),hash(“192.168.1.109#2”)

此时,环形空间中不再有物理节点node1,node2,只有虚拟节点node1-1,node1-2,node2-1,node2-2。由于虚拟节点数量较多,缓存key与虚拟节点的映射关系也变得相对均衡了。

file
file
file
file
file

文章转载自公众号:程序员小灰

正文到此结束
本文目录