好比你有 N 个 cache 服务器(后面简称 cache ),那么如何将一个对象 object 映射到 N 个 cache 上呢,你极可能会采用相似下面的通用方法计算 object 的 hash 值,而后均匀的映射到到 N 个 cache ;node
hash(object)%N算法
hash算法和hash表再认识
散列算法把任意长度的输入变换成固定长度的输出,该输出就是散列值。这种转换是一种压缩映射,也就是,散列值的空间一般远小于输入的空间,不一样的输入可能会散列成相同的输出,而不可能从散列值来惟一的肯定输入值,简言之,将任意长度的消息压缩到某一固定长度的消息摘要的函数。当使用哈希表进行查询的时候,就是再次使用哈希函数将key转换为对应的数组下标,并定位到该空间获取value,如此一来,就能够充分利用到数组的定位性能进行数据定位。sql
一切都运行正常,再考虑以下的两种状况;数据库
1 和 2 意味着什么?这意味着忽然之间几乎全部的 cache 都失效了。对于服务器而言,这是一场灾难,洪水般的访问都会直接冲向后台服务器;数组
再来考虑第三个问题,因为硬件能力愈来愈强,你可能想让后面添加的节点多作点活,显然上面的 hash 算法也作不到。服务器
有什么方法能够改变这个情况呢,这就是 consistent hashing...架构
Hash 算法的一个衡量指标是单调性( Monotonicity ),定义以下:nosql
单调性是指若是已经有一些内容经过哈希分派到了相应的缓冲中,又有新的缓冲加入到系统中。哈希的结果应可以保证原有已分配的内容能够被映射到原有的或者新的缓冲中去,而不会被映射到旧的缓冲集合中的其余缓冲区分布式
容易看到,上面的简单 hash 算法 hash(object)%N 难以知足单调性要求。函数
consistent hashing 是一种 hash 算法,简单的说,在移除 / 添加一个 cache 时,它可以尽量小的改变已存在key 映射关系,尽量的知足单调性的要求。
下面就来按照 5 个步骤简单讲讲 consistent hashing 算法的基本原理。
考虑一般的 hash 算法都是将 value 映射到一个 32 为的 key 值,也便是 0~2^32-1 次方的数值空间;咱们能够将这个空间想象成一个首( 0 )尾( 2^32-1 )相接的圆环,以下面图 1 所示的那样。
图 环形hash空间
接下来考虑 4 个对象 object1~object4 ,经过 hash 函数计算出的 hash 值 key 在环上的分布如图 2 所示。
hash(object1) = key1;
… …
hash(object4) = key4;
图 4个对象的key值分布
Consistent hashing 的基本思想就是将对象和 cache 都映射到同一个 hash 数值空间中,而且使用相同的 hash算法。
假设当前有 A,B 和 C 共 3 台 cache ,那么其映射结果将如图 3 所示,他们在 hash 空间中,以对应的 hash 值排列。
hash(cache A) = key A;
… …
hash(cache C) = key C;
图 cache和对象的key值分布
说到这里,顺便提一下cache的hash计算,通常的方法可使用 cache 机器的 IP 地址或者机器名做为hash输入。
如今 cache 和对象都已经经过同一个 hash 算法映射到 hash 数值空间中了,接下来要考虑的就是如何将对象映射到 cache 上面了。
在这个环形空间中,若是沿着顺时针方向从对象的 key 值出发,直到碰见一个 cache ,那么就将该对象存储在这个 cache 上,由于对象和 cache 的 hash 值是固定的,所以这个 cache 必然是惟一和肯定的。这样不就找到了对象和 cache 的映射方法了吗?!
依然继续上面的例子(参见图 3 ),那么根据上面的方法,对象 object1 将被存储到 cache A 上; object2 和object3 对应到 cache C ; object4 对应到 cache B ;
前面讲过,经过 hash 而后求余的方法带来的最大问题就在于不能知足单调性,当 cache 有所变更时, cache会失效,进而对后台服务器形成巨大的冲击,如今就来分析分析 consistent hashing 算法。
3.5.1 移除cache
考虑假设cache B挂掉了,根据上面讲到的映射方法,这时受影响的将仅是那些沿 cache B 逆时针遍历直到下一个 cache ( cache C )之间的对象,也便是原本映射到 cache B 上的那些对象。
所以这里仅须要变更对象 object4 ,将其从新映射到 cache C 上便可;参见图 4 。
图 Cache B被移除后的cache映射
3.5.2 添加 cache
再考虑添加一台新的 cache D 的状况,假设在这个环形 hash 空间中, cache D 被映射在对象 object2 和object3 之间。这时受影响的将仅是那些沿 cache D 逆时针遍历直到下一个 cache ( cache B )之间的对象(它们是也原本映射到 cache C 上对象的一部分),将这些对象从新映射到 cache D 上便可。
所以这里仅须要变更对象 object2 ,将其从新映射到 cache D 上;参见图 5 。
图 添加cache D后的映射关系
考量 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 值排列。
仍以仅部署 cache A 和 cache C 的状况为例,在图 4 中咱们已经看到, cache 分布并不均匀。如今咱们引入虚拟节点,并设置“复制个数”为 2 ,这就意味着一共会存在 4 个“虚拟节点”, cache A1, cache A2 表明了 cache A ; cache C1, cache C2 表明了 cache C ;假设一种比较理想的状况,参见图 6 。
图 引入“虚拟节点”后的映射关系
此时,对象到“虚拟节点”的映射关系为:
objec1->cache A2 ; objec2->cache A1 ; objec3->cache C1 ; 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 值:
Hash(“202.168.14.241#1”); // cache A1
Hash(“202.168.14.241#2”); // cache A2
当系统中的服务器发生变化时,一致性hash算法能够把系统中数据存储须要改变的数据减小到最少,将系统中节点增减对系统的影响下降到最少,具备较好地可扩展性。
参考资料
《大数据挑战与nosql数据库技术》
《大型分布式网站架构设计与实践》