Redis：一致性Hash算法

问题产生

为了保证Redis服务的高可用性或提高读写性能，许多时候我们会做主从复制，组成 Master-Master 或者 Master-Slave的形式，或者搭建Redis集群，进行读写分离，类似于数据库的主从复制和读写分离。如下图所示：

图1 Redis集群主从架构

但是，一个Redis主服务器并不能满足我们对于读写的需求。当数据量太大时，显然会超出一台机器的承载范围，这时候我们就会考虑将数据分散到多个Redis服务器上，类似于MySQL的分库分表操作。

随机存放的策略

设想一下如下场景：我们有2000w张图片以键值对（文件名 -> 文件）的形式存放在由8台Redis服务器组成的集群中。其中四台作为Master另外4台分别作为这4台Master的Slaver，这样每台服务器上各有500w张图片。集群架构如下图所示：

图2 随机存放导致全集群扫描

2000w张图片中的任意一张都有可能存储在四组Redis主从小组中。因此如果我们要根据图片名称查询一张图片的话，需要同时查询四台Master服务器才能查出结果。这显然不是我们想要的结果。一个简单的小想法应运而生：增加图片存储规则，让我们可以通过文件名知道这个文件到底在哪个服务器上。这种方法有很多，比如Hash取模、按类别、按照某一字段值，这也是MySQL常用的一些分库分表规则。按照我们需要讲解的线索，我们接下来讲解使用Hash方法确定服务器。

Hash取模存放的策略

利用Hash取模方式去判断数据在哪台服务器上，这个操作非常简单。比如我们想查找文件名为“a.png”的图片，则先利用hash函数求得hash值

long hashCode = hash("a.png");

然后hashCode对服务器个数取模，便可得到服务器的index：

int redisServIndex = hashCode % servNum;

假设我们求得的redisServIndex = 0，也就表示我们想访问的图片在服务器0上面，查询过程如下图所示：

图3 hash取模方式查找图片所在服务器

使用Hash取模方式的问题

上面的方法确实提高了性能，避免了全集群查询，能够直接根据文件名得出文件所在服务器位置。但是如果其中一组Redis服务器发生了故障，那么所有的图片文件都要重新转移存储位置才能让hash取模得到的index再次正确。例如，如果第一组Redis服务器挂掉了，那么servNum就从4变成了3，计算位置时就变成了redisServIndex = hashCode % 3，可想而知这时候相同hashCode得出的结果跟之前完全不同。

如果一组Redis服务器停止提供服务，那么将会导致在一段时间内所有Redis缓存失效，引发缓存雪崩。而一致性hash算法就是来解决Redis服务器集群收缩或扩容时会引发缓存雪崩这一问题的。

一致性Hash算法

一致性hash算法本质上也是hash取模算法，只不过并不是对服务器数量取模而是对一个固定的数值2^32取模。简单来说，hash值空间被定义成了一个虚拟的圆环，圆环顺时针递增，其示意图如下：

图4 hash环示意图

有了这个hash环以后,我们将Redis服务器hash到这个环上，一般使用ip地址或者主机名字作为key。如下图所示：

图5 将主机分配到hash环上

接下来，我们看一下如何找到某个元素在哪个服务器上。我们还是将图片名使用hash函数取hashCode，然后hashCode对2^32取模，得到的结果映射到hash环上。从映射位置出发顺时针搜索，找到的第一个Redis服务器就是该图片所在的Redis服务器。

一致性hash算法的容错性和可扩展性

考虑一下如果node b突然下线了会发生什么情况。我们会发现，其他服务器扔然能够正常返回自己负责的那部分数据，只是本来应该由node b负责的数据，这时会去访问node b的下一个服务器node c。

当我们增加一台服务器时会发生什么呢，假如我们在 node b 和 node c 之间增加一台服务器 node x， 那么这台服务器实际上负责存储的数据就是 hashCode 对 2^32 取模后落到 b 和 x 之间的数据。它分担了node c的一部分数据访问需求。

hash环的数据倾斜问题

如果服务器节点太少，有可能会出现数据倾斜问题。被缓存的对象大部分缓存在其中一部分服务器上，而其他服务器则处于非常清闲的状态。例如，如果只有两台服务器，它们的分布情况如下图所示：

图6 一致性hash的数据倾斜问题

从上图中我们看到，大部分数据都被缓存在了B上，而A上只有很少一点。

为了解决这个问题，一致性hash算法引入了虚拟节点的机制。一台服务器会被多次映射到hash环的不同地方，而不是一台服务器就只在hash换上有一个结点。比如 Node A 之外，我们还可以引入虚拟的 Node A #1 ~ Node A #9 这九台虚拟服务器，都映射到hash环上。虚拟节点越多，再配合更加均匀的hash算法，就可以让节点均匀分散在hash环上，从而解决了数据倾斜问题。

总结

• 为了解决全集群搜索，引入了hash取模法
• 为了解决hash取模法在收缩和扩展时的缺陷，引入了一致性hash
• 服务器和数据都映射到hash环上，数据所处位置顺时针最近的服务器就是缓存该数据的服务器
• 为了解决数据倾斜问题引入了虚拟节点的机制
• 为每个服务器增加多个虚拟节点，均匀映射到hash环上，访问虚拟节点想到关于访问对应的真实服务器