Redis集群一致性哈希算法

一、算法背景

一致性哈希算法在1997年由麻省理工学院的Karger等人在解决分布式Cache中提出的,设计目标是为了解决因特网中的热点(Hot spot)问题,初衷和CARP十分类似。一致性哈希修正了CARP使用的简单哈希算法带来的问题,使得DHT可以在P2P环境中真正得到应用。

但现在一致性哈希算法在分布式系统中也得到了广泛应用,研究过memcached缓存数据库的人都知道,memcached服务器端本身不提供分布式cache的一致性,而是由客户端来提供,具体步骤如下:

  1. 首先求出memcached服务器(节点)的哈希值,并将其配置到0~2^32的圆(continuum)上。

  2. 然后采用同样的方法求出存储数据的键的哈希值,并映射到相同的圆上。

  3. 然后从数据映射到的位置开始顺时针查找,将数据保存到找到的第一个服务器上。如果超过2^32仍然找不到服务器,就会保存到第一台memcached服务器上。


Redis集群一致性哈希算法

一致性哈希环


如果在上图的一致性哈希环上添加一台memcached服务器,则余数分布式算法由于保存键的服务器会发生巨大变化而影响缓存的命中率,但一致性哈希算法中,只有在圆(continuum)上增加服务器的地点与其逆时针方向的第一台服务器之间的键会受到影响,如下图所示:


Redis集群一致性哈希算法

一致性哈希环增加节点


二、一致性哈希的特性

1. 平衡性(Balance)

平衡性是指哈希的结果能够尽可能分布到所有的节点中去,这样可以使得所有的节点空间都得到利用。很多哈希算法都能够满足这一条件。

2. 单调性(Monotonicity)

如果已经有一些数据通过一致性哈希算法分配到了对应的节点中,此时又有新的节点接入到一致性哈希环上,则哈希的结果应该能保证原有数据可以被映射到新的节点中去,而不是依旧将数据映射到已有的旧的节点上。

3. 分散性(Spread)

在分布式系统中,客户端可能无法感知到一致性哈希环上的所有节点,只能看到部分节点。客户端希望通过哈希过程将数据映射到哈希环上,由于不同客户端感知到的一致性哈希环的节点可能不同,可能会产生相同的数据在不同的客户端被映射到不同的节点上。这种情况应该是要避免的。好的哈希算法应能够尽量避免不一致的情况发生,也就是尽量降低分散性。

4. 负载(Load)

负载是从另一个角度看待分散性问题。不同的客户端可能会将相同的内容映射到不同的节点上,那么对于同一个节点而言,也可能被不同的客户端存储不同的内容。这种情况应该避免,好的哈希算法应该尽量降低节点的负载。

5. 平滑性(Smoothness)

节点数量的平滑变化和数据的平滑改变是一致的。

三、一致性哈希算法原理

一致性哈希算法(Consistent Hashing)最早在论文《Consistent Hashing and Random Trees: Distributed Caching Protocols for Relieving Hot Spots on the World Wide Web》中被提出。简单来说,一致性哈希将整个哈希值空间组织成一个虚拟的圆环,如假设某哈希函数H的值空间为0-232-1(即哈希值是一个32位无符号整形),整个哈希空间环如下。整个空间按顺时针方向组织。0和232-1在零点中方向重合。


Redis集群一致性哈希算法

哈希空间


下一步将各个服务器使用哈希函数进行个哈希,具体可以选择服务器的ip或主机名作为关键字进行哈希,这样每台机器就能确定其在哈希环上的位置,这里假设将4台服务器使用ip地址哈希后在环空间的位置如下:


Redis集群一致性哈希算法

ip地址哈希

接下来使用如下算法规定数据访问相应服务器:将数据key使用相同的函数哈希函数计算出哈希值,并确定此数据在环上的位置,从此位置沿环“顺时针行走”,第一台遇到的服务器就是其应该定位到的服务器。

例如我们有Object A、Object B、Object C、Object D四个数据对象,经过哈希计算后,在环空间上的位置如下:


Redis集群一致性哈希算法

一致性哈希算法数据分布

根据上述算法约定,数据A会被定为到Node A上,B被定为到Node B上,C被定为到Node C上,D被定为到Node D上。

四、一致性哈希算法容错性

现假设Node C不幸宕机,可以看到此时对象A、B、D不会受到影响,只有对象C会收到影响,对象C会被重新定位到Node D。

在一致性哈希算法中,如果一台服务器不可用,则受影响的数据仅仅是此服务器到其环空间中前一台服务器(即沿着逆时针方向行走遇到的第一台服务器)之间数据,其它不会受到影响。

五、一致性哈希算法扩展性

如果在系统中增加一台服务器Node X,如下图所示:


Redis集群一致性哈希算法

一致性哈希扩容


此时对象Object A、B、D不受影响,只有对象C需要重定位到新的Node X 。一般的,在一致性哈希算法中,如果增加一台服务器,则受影响的数据仅仅是新服务器到其环空间中前一台服务器(即沿着逆时针方向行走遇到的第一台服务器)之间数据,其它数据也不会受到影响。

综上所述,一致性哈希算法对于节点的增减都只需重定位环空间中的一小部分数据,具有较好的容错性和可扩展性。

六、一致性哈希算法改进

当服务器数量较少时,一致性哈希算法容易因为节点分部不均匀而造成数据倾斜问题。例如系统中只有两台服务器,一致性哈希环分布如下。


Redis集群一致性哈希算法

一致性哈希环只有两个节点


如果输入的数据很容易造成大量数据集中到Node A上,而只有极少量会定位到Node B上。如输入1000个数字,其中基数为750个,偶数为250个。

为了解决这种数据倾斜问题,一致性哈希算法引入了虚拟节点机制:即对每一个服务节点计算多个哈希,每个计算结果位置都放置一个此服务节点,称为“虚拟节点”。

具体做法可以在服务器ip或主机名的后面增加编号来实现。例如上面的情况,可以为每台服务器计算三个虚拟节点,于是可以分别计算 “Node A#1”、“Node A#2”、“Node A#3”、“Node B#1”、“Node B#2”、“Node B#3”的哈希值,于是形成六个虚拟节点:


Redis集群一致性哈希算法

一致性哈希环增加虚拟节点


保持数据定位算法不变,只是多了一步虚拟节点到实际节点的映射,例如定位到“Node A#1”、“Node A#2”、“Node A#3”三个虚拟节点的数据均定位到Node A上。这样就解决了服务节点少时数据倾斜的问题。在实际应用中,通常将虚拟节点数设置为32甚至更大,因此即使很少的服务节点也能做到相对均匀的数据分布。


原文始发于微信公众号(落叶飞翔的蜗牛):Redis集群一致性哈希算法

版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 举报,一经查实,本站将立刻删除。

文章由极客之音整理,本文链接:https://www.bmabk.com/index.php/post/20709.html

(0)
小半的头像小半

相关推荐

发表回复

登录后才能评论
极客之音——专业性很强的中文编程技术网站,欢迎收藏到浏览器,订阅我们!