一致性哈希(consistent hashing)算法

Posted 2020-08-05 朗度云

文章同步发表在博主的网站朗度云，传输门：http://www.wolfbe.com/detail/201608/341.html

1、背景

       我们都知道memcached服务器是不提供分布式功能的，memcached的分布式完全是由客户端来实现的。在部署memcached服务器集群时，我们需要把缓存请求尽可能分散到不同的缓存服务器中，这样可以使得所有的缓存空间都得到利用，而且可以降低单独一台缓存服务器的压力。
     最简单的一种实现是，缓存请求时通过计算key的哈希值，取模后映射到不同的memcahed服务器。这种简单的实现在不考虑集群机器动态变化的情况下也是比较有效的一种方案，但是，在分布式集群系统中，简单取模的哈希算法存在很多的不足。在动态变化的缓存集群中，有四个判断哈希算法好坏的标准：

• 平衡性(blance)：指哈希的结果能够尽可能映射到所有的节点，这样所有节点的资源都能够得到利用。
• 单调性(monotonicity)：指如果有一些数据通过哈希分派到相应的节点中，又有新的节点加入系统中，那么哈希的结果应该能够保证已分配的内容可以被映射到原有的或者新的节点中，而不会被映射到旧系统(加入新的节点之前)的其它节点。
• 分散性(spread)：在分布式环境中，终端有可能看不到所有的节点，而是只能看到一部分。当终端通过哈希过程分派到节点上时，由于不同的终端所看到的节点范围有可能不一样，从而导致哈希的结果不一样，最终会出现相同的内容会被不同的终端哈希到不同的节点上存储。这种情况应该要避免，因为这样相同的内容会被存储不同的节点，浪费系统的资源。
• 负载(load)：负载问题实际上是从另一个角度看待分散性问题。既然不同的终端可能将相同的内容映射到不同的节点中，那么对于一个特定的节点而言，也可能被不同的终端映射为不同的内容。与分散性一样，这种情况也是应当避免的，因此好的哈希算法应能够尽量降低节点的负荷。

       在分布式的集群系统中，机器的增加或移除或机器故障宕机的情况经常发生，如果使用简单取模的哈希算法，机器变化了计算的算法也要重新修改，存储的对象的位置也必须改变，外部服务访问就可能无法命中原来的内容，导致缓存后端服务压力过大而崩溃。所以，简单取模的这种哈希算法不能满足动态变化的缓存集群环境，因此需要其它的算法来避免这样的问题。

 

       一致性哈希算法在1997年由麻省理工学院的Karger等人在解决分布式Cache中提出的，主要是为了解决因特网中的热点(Hot spot)问题。目前这一思想已经扩展到其它的领域，并且在实践中得到了很大的发展。目前很多应用都会一致性哈希算法应用在动态变化的缓存集群中，它能够满足上面提到的四个标准。

     

2、原理

       哈希，也叫做散列，就是把任意长度的输入通过散列算法，变换成固定长度的输出，该输出就是散列值，或者叫哈希值 。一致性哈希将整个哈希值空间虚拟成一个闭合的Hash环，假设哈希值空间为2的32次方，即哈希值空间为0~ 2^32-1，如下图所示：

图1 Hash环

将对象映射到Hash环

假设有object1、object2、object3、object4四个对象，通过Hash算法计算出它们的Key值，然后映射到Hash环上，如下图所示：

Hash(object1) = key1；

Hash(object2) = key2；

Hash(object3) = key3；

Hash(object4) = key4；

图2 对象哈希

将节点映射到Hash环

假设有Cache A 、Cache B、Cache C三个缓存节点，通过Hash算法计算它们的哈希值，映射到Hash环上，如下图所示：

Hash(Cache A) = Key A;

Hash(Cache B) = Key B;

Hash(Cache C) = Key C;

图3 节点哈希

一般情况下，计算节点的哈希值可以使用节点的IP或者节点的别名作为输入值。需要注意的是计算节点使用的Hash算法跟计算对象使用的Hash算法是一样的，这样节点跟对象的哈希空间也是一样的，按照顺时针的方向，将对象存储在离自己最近的那个节点上。从图3可以看出，object1存储到Cache A节点，object2和object3存储到Cache C节点，object4存储到Cache B节点。

 

节点变动

使用简单取模的哈希算法最大的问题在于当节点数量变动时，节点的数据会失效，那么一致性哈希算法能够避免这些问题，是否能够满足上面的四个标准呢？

• 增加节点

在集群中增加一个新的节点Cache D，假设在Hash环上，节点经过Hash计算后被映射到object2与object3之间，如下图所示：

图4 增加节点

按照顺时针方向存储的约定，object2会迁移存储到Cache D节点，其它对象保持原来位置不变。

 

• 删除节点

假设节点Cache B故障挂掉了，按照顺时针方向存储的约定，object4会迁移存储到Cache C节点，其它对象保持原来位置不变，如下图所示：

图5 删除节点

       经过增加节点和删除节点的分析得到，一致性哈希算法在保持单调性的同时，还让数据的迁移达到最小，避免因为数据迁移造成后端服务器因为压力大而崩溃。

 

平衡性设计

       通过上面的分析得到，一致性哈希算法可以满足动态缓存集群系统的单调性、分散性、负载的标准，但还不能确定它的设计是否能够满足平衡性。下面将讲解一致性哈希算法是如何做到满足平衡性的。

       在删除节点的例子中，系统中只有Cache A与Cache C这两个节点，object1存储到Cache A节点，object2、object3、object4存储到Cache C节点，分布很明显不平衡。

       为了解决这个问题，一致性算法中引入了虚拟节点的概念，虚拟节点是实际节点在Hash环上的复制器，一个实际节点可以对应多个虚拟节点。

       现在假设一个实际点对应2个虚拟节点，经过Hash计算后，映射到Hash环上，这样Hash环上就存在4个虚拟的节点， 如下图所示：

图6 虚拟节点

按顺时针方向存储的约定，object1存储到Cache A2节点，object2存储到Cache A1节点，object3存储到Cache C1节点，object4存储到Cache C2节点。这样的情况是一个比较理想的情况，因此object1、object2存储到Cache A节点，object3、object4存储到Cache C节点上，平衡性得到满足。

 

      引入虚拟节点后，映射关系就从对象->节点变成了对象->虚拟节点，查找对象所在的实际节点时的映射关系图如下所示：

图7 查找节点

虚拟节点的哈希输入可以是实际节点的IP加数字后缀的方式，假设Cache A的IP是192.168.1.100，那么计算Cache A1和Cache A2的Hash值是：

Hash("192.168.1.100 #1") = key C1; 

Hash("192.168.1.100 #2") = key C2; 

      至此我们可以确定，一致性哈希算法能够满足分布式集群的平衡性、单调性、分散性、负载四个标准，现在已经被广泛地应用到各个领域。