分布式系统之一致性哈希算法

Redis是当前分布式架构中经常使用的缓存方案。随着负载上升，集群规模逐步扩大，这时候Redis也有单机发展为集群模式。
Redis的的集群模式比较简单，普遍都采用负载分担模式，即根据一定算法，以缓存数据为输入，计算出一个值cache_key，根据cache_key不同把数据保存到不同的Redis节点。

Key Hash并取模

最简单常用的方式，是对保存数据的Key为输入，对Key计算Hash值，然后以服务器数量对Hash值取模，得到cache_key，把数据保存到对应索引的节点。

cache_key = hash(key) % server_count

示例如下：

这种模式简单除暴，效果也很明显，大家一看就懂，代码实现简单。但是，成人的世界永远没有简单两个字，如果某个Redis节点运行过程中挂了会怎么样？如果负载太高Redis需要扩容怎么办？

简单，根据服务器数量重新计算Hash值呗！我们来看下这种模式会出现什么问题。
因为cache_key值是根据服务器数量取模的，服务器数量变化了后，所有cache_key的值都变了。例如，节点C挂了以后，节点数量由3变为2，那么原来Hash值为3的Key取模后的值由0变为1，这时候Redis查下该Key的时候，缓存肯定命中失败。

这时候，除了0和1两个cache_key的缓存位置没有发生变化，其他数据的位置都发生了变化，缓存命中全部失效，如果此时刚好有海量的客户端请求，所有请求都透传到服务器中，会导致数据库直接挂掉。

固定服务器数量

以上实现方式的主要问题，在于服务器数量发生变化后，计算公式的分母变量，导致所有数据计算出来的值都变了。那我们就想个分母不变的计算公式。
例如，我们把分母固定为128，Redis集群的数量肯定不会超过128台，这样修改后，计算出来的值为0-127，我们只要解决怎么把这128个值分别存到不通节点的方式即可。比如我们以每台服务器的IP为输入，进行Hash后已128取模，公式如下：

node_hash_index = hash(ip) % 128

假设三个节点的node_hash_index值为10,60 101，我们把他们放到一个环上：

• cache_key为0-10和102-127的数据存到A节点
• cache_key为11-60的数据存到B节点
• cache_key为61-101的数据存到C节点

采用这种方式，如果C节点挂了，则只有C节点的数据失效，A和B节点的数据不受影响，C节点的数据重新缓存后保存到A节点中。

但是这种方式有几个问题，会导致节点间负载失衡：

1. 实际情况中，节点node_hash_index的值可能不会这么均匀，如下图所示，B和C节点存储的数据和少，而A节点压力很大。
2. 如果一个节点挂了（例如C节点），原先在这个节点上的所有数据都转到邻居一台节点上去。
3. 如果系统压力上升，增加一个节点，加到环上的某个位置，只能缓解环上相邻节点的压力。

一致性Hash算法

上面描述的节点间负载失衡问题，都是由于节点node_hash_index值不均匀+节点数量太少导致。
Hash值我们无法修改，那有没有办法增加节点数量呢？物理节点数量是不能随便增加的，但我们可以把一个物料节点虚拟成多个节点，给每个节点计算node_hash_index值，节点多了，节点node_hash_index值自然会均匀。比如，我们把每个物理节点虚拟成3个节点，并给节点增加类似01、02、03的编号，服务器的Hash值修改为：

node_hash_index = hash(ip + index) % 128

通过这种方式，我们可以增加节点变动时数据的均衡性，并保持个服务器间负载的均衡性。

在一致性Hash算法应用的时候，一遍会把分母定为2^23。本文只是介绍了一致性Hash算法的原理和Redis缓存中的应用。在日常架构设计中一致性Hash算法有着广泛的应用，比如数据库的分库分表。

一致性Hash性质

一致性哈希算法（Consistent Hashing）最早在论文 Consistent hashing and random trees: distributed caching protocols for relieving hot spots on the World Wide Web 中被提出来的，英文好，有兴趣的同学可以拜读下。

说完了一致性Hash算法的原理，我们再来梳理下理论性的东西。

考虑到分布式系统每个节点都有可能失效，并且新的节点很可能动态的增加进来，如何保证当系统的节点数目发生变化时仍然能够对外提供良好的服务，这是值得考虑的，尤其实在设计分布式缓存系统时，如果某台服务器失效，对于整个系统来说如果不采用合适的算法来保证一致性，那么缓存于系统中的所有数据都可能会失效（即由于系统节点数目变少，客户端在请求某一对象时需要重新计算其hash值（通常与系统中的节点数目有关），由于hash值已经改变，所以很可能找不到保存该对象的服务器节点），因此一致性hash就显得至关重要，良好的分布式cahce系统中的一致性hash算法应该满足以下几个方面：

• 平衡性(Balance)

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

• 单调性(Monotonicity)

单调性是指如果已经有一些内容通过哈希分派到了相应的缓冲中，又有新的缓冲区加入到系统中，那么哈希的结果应能够保证原有已分配的内容可以被映射到新的缓冲区中去，而不会被映射到旧的缓冲集合中的其他缓冲区。简单的哈希算法往往不能满足单调性的要求，如最简单的线性哈希：x = (ax + b) mod (P)，在上式中，P表示全部缓冲的大小。不难看出，当缓冲大小发生变化时(从P1到P2)，原来所有的哈希结果均会发生变化，从而不满足单调性的要求。哈希结果的变化意味着当缓冲空间发生变化时，所有的映射关系需要在系统内全部更新。而在P2P系统内，缓冲的变化等价于Peer加入或退出系统，这一情况在P2P系统中会频繁发生，因此会带来极大计算和传输负荷。单调性就是要求哈希算法能够应对这种情况。

• 分散性(Spread)

在分布式环境中，终端有可能看不到所有的缓冲，而是只能看到其中的一部分。当终端希望通过哈希过程将内容映射到缓冲上时，由于不同终端所见的缓冲范围有可能不同，从而导致哈希的结果不一致，最终的结果是相同的内容被不同的终端映射到不同的缓冲区中。这种情况显然是应该避免的，因为它导致相同内容被存储到不同缓冲中去，降低了系统存储的效率。分散性的定义就是上述情况发生的严重程度。好的哈希算法应能够尽量避免不一致的情况发生，也就是尽量降低分散性。

• 负载(Load)

负载问题实际上是从另一个角度看待分散性问题。既然不同的终端可能将相同的内容映射到不同的缓冲区中，那么对于一个特定的缓冲区而言，也可能被不同的用户映射为不同的内容。与分散性一样，这种情况也是应当避免的，因此好的哈希算法应能够尽量降低缓冲的负荷。

• 平滑性(Smoothness)

平滑性是指缓存服务器的数目平滑改变和缓存对象的平滑改变是一致的。