一致性哈希

哈希函数

哈希函数是一种计算方法，它可以把一个值A映射到一个特定的范围[begin, end]之内。对于一个值的集合{k1, k2, … , kN}，哈希函数把他们均匀的映射到某个范围之中。这样，通过这些值就可以很快的找到与之对应的映射地址{index1, index2, … , indexN}。对于同一个值，哈希函数要能保证对这个值的运算结果总是相同的。

哈希函数需要经过精心设计才能够达到比较好的效果，但是总是无法达到理想的效果。多个值也许会映射到同样的地址上。这样就会产生冲突，如图中的红线所示。在设计哈希函数时要尽量减少冲突的产生。

最简单的哈希函数就是一个求余运算： hash(A) = A % N。这样就把A这个值映射到了[0~N-1]这样一个范围之中。

哈希表

哈希表的核心就是哈希函数hash()。

哈希表是一中数据结构，它把KEY 和 VALUE用某种方式对应起来。使用hash()函数把一个KEY值映射到一个index上，即hash(KEY) = index。这样就可以把一个KEY值同某个index对应起来。然后把与这个KEY值对应的VALUE存储到index所标记的存储空间中。这样，每次想要查找KEY所对应的VALUE值时，只需要做一次hash()运算就可以找到了。

举个例子：图书馆中的书会被某人借走，这样“书名”和“人名”之间就形成了KEY与VALUE的关系。假设现在有三个记录：

简明现代魔法	小明
最后一天	小红
变形记	小红

这就是“书名”和“人名”的对应关系，它表示某人借了某本书。现在我们把这种对应关系用哈希表存储起来，它们的hash()值分别为：

hash(简明现代魔法) = 2

hash(最后一天) = 0

hash(变形记) = 1

然后我们就可以在一个表中存储“人名”了：

0	小红
1	小红
2	小明

这三个人名分别存储在0、1和2号存储空间中。当我们想要查找《简明现代魔法》这本书是被谁借走的时候，只要hash()一下这个书名，就可以找到它所对应的index，为2。然后在这个表中就可以找到对应的人名了。在这里，KEY为“书名”， VALUE为“人名”。

当有大量的KEY VALUE对应关系的数据需要存储时，这种方法就非常有效。

分布式哈希基本场景

比如你有 N 个 cache 服务器（后面简称 cache ），那么如何将一个对象 object 映射到 N 个 cache 上呢，你很可能会采用类似下面的通用方法计算 object 的 hash 值，然后均匀的映射到到 N 个 cache：

hash(object)%N

一切都运行正常，再考虑如下的两种情况：

一个 cache 服务器 m down 掉了（在实际应用中必须要考虑这种情况），这样所有映射到 cache m 的对象都会失效，怎么办，需要把 cache m 从 cache 中移除，这时候 cache 是 N-1 台，映射公式变成了 hash(object)%(N-1) ；
由于访问加重，需要添加 cache ，这时候 cache 是 N+1 台，映射公式变成了 hash(object)%(N+1) ；

1 和 2 意味着什么？这意味着突然之间几乎所有的 cache 都失效了。对于服务器而言，这是一场灾难，洪水般的访问都会直接冲向后台服务器；

再来考虑第三个问题，由于硬件能力越来越强，你可能想让后面添加的节点多做点活，显然上面的 hash 算法也做不到。有什么方法可以改变这个状况呢，这就是 consistent hashing 一致性 hash 算法...

hash 算法和单调性

Hash 算法的一个衡量指标是单调性（ Monotonicity ），定义如下：

单调性是指如果已经有一些内容通过哈希分派到了相应的缓冲中，又有新的缓冲加入到系统中。哈希的结果应能够保证原有已分配的内容可以被映射到新的缓冲中去，而不会被映射到旧的缓冲集合中的其他缓冲区。

容易看到，上面的简单 hash 算法 hash(object)%N 难以满足单调性要求。

consistent hashing 算法的原理

consistent hashing 是一种 hash 算法，简单的说，在移除 / 添加一个 cache 时，它能够尽可能小的改变已存在 key 映射关系，尽可能的满足单调性的要求。

一致性hash算法提出了在动态变化的Cache环境中，判定哈希算法好坏的四个定义：

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

（2）单调性(Monotonicity)：单调性是指如果已经有一些内容通过哈希分派到了相应的缓冲中，又有新的缓冲加入到系统中。哈希的结果应能够保证原有已分配的内容可以被映射到原有的或者新的缓冲中去，而不会被映射到旧的缓冲集合中的其他缓冲区。

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

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

下面就来按照 5 个步骤简单讲讲 consistent hashing 算法的基本原理。

1. 环形hash 空间

考虑通常的 hash 算法都是将 value 映射到一个 32 为的 key 值，也即是 0~2^32-1 次方的数值空间；我们可以将这个空间想象成一个首（ 0 ）尾（ 2^32-1 ）相接的圆环，如下图所示的那样。

2. 把对象映射到hash 空间

接下来考虑 4 个对象 object1~object4 ，通过 hash 函数计算出的 hash 值 key 在环上的分布如下图所示。

1
hash(object1) = key1;

2
… …

3
hash(object4) = key4;

4 个对象的 key 值分布

3. 把cache 映射到hash 空间

Consistent hashing 的基本思想就是将对象和 cache 都映射到同一个 hash 数值空间中，并且使用相同的 hash 算法。假设当前有 A,B 和 C 共 3 台 cache ，那么其映射结果将如图 3 所示，他们在 hash 空间中，以对应的 hash 值排列。

1
hash(cache A) = key A;

2
… …

3
hash(cache C) = key C;

cache 和对象的 key 值分布

说到这里，顺便提一下 cache 的 hash 计算，一般的方法可以使用 cache 机器的 IP 地址或者机器名作为 hash 输入。

4. 把对象映射到cache

现在 cache 和对象都已经通过同一个 hash 算法映射到 hash 数值空间中了，接下来要考虑的就是如何将对象映射到 cache 上面了。

在这个环形空间中，如果沿着顺时针方向从对象的 key 值出发，直到遇见一个 cache ，那么就将该对象存储在这个 cache 上，因为对象和 cache 的 hash 值是固定的，因此这个 cache 必然是唯一和确定的。这样不就找到了对象和 cache 的映射方法了吗？！

依然继续上面的例子（上图），那么根据上面的方法：

对象 object1 将被存储到 cache A 上；
object2和 object3 对应到 cache C ；
object4 对应到 cache B。

5. 考察cache 的变动

前面讲过，通过 hash 然后求余的方法带来的最大问题就在于不能满足单调性，当 cache 有所变动时， cache 会失效，进而对后台服务器造成巨大的冲击，现在就来分析分析 consistent hashing 算法。

考虑假设 cache B 挂掉了，根据上面讲到的映射方法，这时受影响的将仅是那些沿 cache B 逆时针遍历直到下一个 cache （ cache C ）之间的对象，也即是本来映射到 cache B 上的那些对象。

因此这里仅需要变动对象 object4 ，将其重新映射到 cache C 上即可：

Cache B 被移除后的 cache 映射

再考虑添加一台新的 cache D 的情况，假设在这个环形 hash 空间中， cache D 被映射在对象 object2 和 object3 之间。这时受影响的将仅是那些沿 cache D 逆时针遍历直到下一个 cache （ cache B ）之间的对象（它们是也本来映射到 cache C 上对象的一部分），将这些对象重新映射到 cache D 上即可。

因此这里仅需要变动对象 object2 ，将其重新映射到 cache D 上：

添加 cache D 后的映射关系

consistent hashing的优点和缺点

相比于普通哈希方式，一致性哈希的好处就是：当添加新机器或者删除机器时，不会影响到全部数据的存储，而只是影响到这台机器上所存储的数据(落在这台机器所负责的环上的数据)。

比如，B机器被移除了，那落在（A,B）范围内的数据全部需要由 C机器来存储，也就只影响到落在（A,B）这个范围内的数据。

同时，扩容也很方便，比如在（C,D）这段环上再添加一台机器E，只需要将D上的一部分数据拷贝到机器E上即可。

那一致性哈希有没有缺点呢？当然是有的。总结一下就是：没有考虑到每台机器的异构性质，不能实现很好的负载均衡。

举个例子：机器C的配置很高，性能很好，而机器D的配置很低。但是，可能现实中大部分数据由于某些特征都哈希到（C,D）这段环上，直接就导致了机器D的存储压力很大。

另外，一致性哈希还存在“热点”问题（hotspot）。

比如说，由于机器D上存储了大量的数据，为了缓解下机器D的压力，在环（C,D）段再添加一台机器E，就需要将机器D上的一部分数据拷贝到机器E上。而且只有一台机器：即机器D参与拷贝，这会引起机器D 与机器 E之间的网络负载突然增大。机器D，就是我们所说的hotspot。

虚拟节点

考量 Hash 算法的另一个指标是平衡性 (Balance) ，定义如下：

平衡性是指哈希的结果能够尽可能分布到所有的缓冲中去，这样可以使得所有的缓冲空间都得到利用。

hash 算法并不是保证绝对的平衡，如果 cache 较少的话，对象并不能被均匀的映射到 cache 上，比如在上面的例子中，仅部署 cache A 和 cache C 的情况下，在 4 个对象中， cache A 仅存储了 object1 ，而 cache C 则存储了 object2 、 object3 和 object4 ；分布是很不均衡的。

为了解决这种情况， consistent hashing 引入了“虚拟节点”的概念，它可以如下定义：

“虚拟节点”（ virtual node ）是实际节点在 hash 空间的复制品（ replica ），一实际个节点对应了若干个“虚拟节点”，这个对应个数也成为“复制个数”，“虚拟节点”在 hash 空间中以 hash 值排列。

引入虚拟节点，可以有效地防止物理节点(机器)映射到哈希环中出现不均匀的情况。比如上面介绍的consistent hashing优缺点图中的机器A、B、C都映射在环的右半边上。

一般，虚拟节点会比物理节点多很多，并可均衡分布在环上，从而可以提高负载均衡的能力。如下图：

①如果虚拟机器与物理机器映射得好，某一台物理机器宕机后，其上的数据可由其他若干台物理机器共同分担。

②如果新添加一台机器，它可以对应多个不相邻 环段上的虚拟节点，从而使得hash的数据存储得更分散。

另外，对于英文图中的例子，仍以仅部署 cache A 和 cache C 的情况为例，在前面中我们已经看到， cache 分布并不均匀。现在我们引入虚拟节点，并设置“复制个数”为 2 ，这就意味着一共会存在 4 个“虚拟节点”， cache A1, cache A2 代表了 cache A ； cache C1, cache C2 代表了 cache C ；假设一种比较理想的情况，参见下图。

引入“虚拟节点”后的映射关系

此时，对象到“虚拟节点”的映射关系为：

1
objec1->cache A2

2
objec2->cache A1

3
objec3->cache C1

4
objec4->cache C2 ；

因此对象 object1 和 object2 都被映射到了 cache A 上，而 object3 和 object4 映射到了 cache C 上；平衡性有了很大提高。引入“虚拟节点”后，映射关系就从 { 对象 -> 节点 } 转换到了 { 对象 -> 虚拟节点 } 。查询物体所在 cache 时的映射关系如图 7 所示。

查询对象所在 cache

“虚拟节点”的 hash 计算可以采用对应节点的 IP 地址加数字后缀的方式。例如假设 cache A 的 IP 地址为 202.168.14.241 。

引入“虚拟节点”前，计算 cache A 的 hash 值：Hash("202.168.14.241");

引入“虚拟节点”后，计算“虚拟节”点 cache A1 和 cache A2 的 hash 值：

`1`	`Hash("202.168.14.241#1");` `// cache A1`

`2`	`Hash("202.168.14.241#2");` `// cache A2`

本文参考自：

http://www.nowamagic.net/librarys/veda/detail/1337

http://www.nowamagic.net/librarys/veda/detail/1336

http://blog.csdn.net/cywosp/article/details/23397179

https://www.cnblogs.com/hapjin/p/5760463.html