[转]哈希分布与一致性哈希算法简介

哈希分布与一致性哈希算法简介

作者：liunx

来源：http://www.cnblogs.com/liunx/archive/2010/03/24/1693925.html

前言
在我们的日常web应用开发当中memcached可以算作是当今的标准开发配置了。相信memcache的基本原理大家也都了解过了，memcache虽然是分布式的应用服务，但分布的原则是由client端的api来决定的，api根据存储用的key以及已知的服务器列表，根据key的hash计算将指定的key存储到对应的服务器列表上。

基本的原理以及分布
在这里我们通常使用的方法是根据 key的hash值%服务器数取余数 的方法来决定当前这个key的内容发往哪一个服务器的。这里会涉及到一个hash算法的分布问题，哈希的原理用一句话解释就是两个集合间的映射关系函数，在我们通常的应用中基本上可以理解为 在集合A（任意字母数字等组合，此处为存储用的key）里的一条记录去查找集合B（如0-2^32）中的对应记录。（题外话：md5的碰撞或者说冲突其实就是发生在这里，也就是说多个A的记录映射到了同一个B的记录）

实际应用
显然在我们的应用中集合A的记录应该更均匀的分布在集合B的各个位置，这样才能尽量避免我们的数据被分布发送到单一的服务器上，在danga的memcached的原始版本（perl）中使用的是crc32的算法用java的实现写出来：
private static int origCompatHashingAlg( String key ) {
int hash = 0;
char[] cArr = key.toCharArray();

for ( int i = 0; i < cArr.length; ++i ) {
hash = (hash * 33) + cArr[i];
}

return hash;
}
这里还有另一个改进版本的算法：
private static int newCompatHashingAlg( String key ) {
CRC32 checksum = new CRC32();
checksum.update( key.getBytes() );
int crc = (int) checksum.getValue();

return (crc >> 16) & 0x7fff;
}

分布率测试
有人做过测试，随机选择的key在服务器数量为5的时候所有key在服务器群组上的分布概率是：
origCompatHashingAlg:
0 10%
1 9%
2 60%
3 9%
4 9%

newCompatHashingAlg:
0 19%
1 19%
2 20%
3 20%
4 20%

显然使用旧的crc32算法会导致第三个memcached服务的负载更高，但使用新算法会让服务之间的负载更加均衡。
其他常用的hash算法还有FNV-1a Hash,RS Hash,JS Hash,PJW Hash,ELF Hash,AP Hash等等。有兴趣的童鞋可以查看这里：

http://www.partow.net/programming/hashfunctions/

http://hi.baidu.com/algorithms/blog/item/79caabee879ece2a2cf53440.html

小结
至此我们了解到了在我们的应用当中要做到尽量让我们的映射更加均匀分布，可以使服务的负载更加合理均衡。

新问题
但到目前为止我们依然面对了这样一个问题：就是服务实例本身发生变动的时候，导致服务列表变动从而会照成大量的cache数据请求会miss，几乎大部分数据会需要迁移到另外的服务实例上。这样在大型服务在线时，瞬时对后端数据库/硬盘照成的压力很可能导致整个服务的crash。

一致性哈希（Consistent Hashing）
在此我们采用了一种新的方式来解决问题，处理服务器的选择不再仅仅依赖key的hash本身而是将服务实例（节点）的配置也进行hash运算。

1. 首先求出每个服务节点的hash，并将其配置到一个0~2^32的圆环（continuum）区间上。
2. 其次使用同样的方法求出你所需要存储的key的hash，也将其配置到这个圆环（continuum）上。
3. 然后从数据映射到的位置开始顺时针查找，将数据保存到找到的第一个服务节点上。如果超过2^32仍然找不到服务节点，就会保存到第一个memcached服务节点上。

整个数据的图例：

当增加服务节点时：

其他：只有在圆环上增加服务节点的位置为逆时针方向的第一个服务节点上的键会受到影响。

小结
一致性哈希算法最大程度的避免了key在服务节点列表上的重新分布，其他附带的改进就是有的一致性哈希算法还增加了虚拟服务节点的方法，也就是一个服务节点在环上有多个映射点，这样就能抑制分布不均匀，
最大限度地减小服务节点增减时的缓存重新分布。

应用
在memcached的实际应用，虽然官方的版本并不支持Consistent Hashing，但是已经有了现实的Consistent Hashing实现以及虚节点的实现，第一个实现的是last.fm（国外流行的音乐平台）开发的libketama，
其中调用的hash的部分的java版本的实现（基于md5）：
/**
* Calculates the ketama hash value for a string
* @param s
* @return
*/
public static Long md5HashingAlg(String key) {

if(md5==null) {
try {
md5 = MessageDigest.getInstance("MD5");
} catch (NoSuchAlgorithmException e) {
log.error( "++++ no md5 algorythm found" );
throw new IllegalStateException( "++++ no md5 algorythm found");
}
}

md5.reset();
md5.update(key.getBytes());
byte[] bKey = md5.digest();
long res = ((long)(bKey[3]&0xFF) << 24) | ((long)(bKey[2]&0xFF) << 16) | ((long)(bKey[1]&0xFF) << 8) | (long)(bKey[0]&0xFF);
return res;
}
在一致性哈希的算法/策略环境中，按照测试来说时间和分布性都是综合来说比较让人满意的，参见：
http://www.javaeye.com/topic/346682

总结
在我们的web开发应用中的分布式缓存系统里哈希算法承担着系统架构上的关键点。
使用分布更合理的算法可以使得多个服务节点间的负载相对均衡，可以最大程度的避免资源的浪费以及服务器过载。
使用一致性哈希算法，可以最大程度的降低服务硬件环境变化带来的数据迁移代价和风险。
使用更合理的配置策略和算法可以使分布式缓存系统更加高效稳定的为我们整体的应用服务。

展望
一致性哈希的算法/策略来源于p2p网络，其实纵观p2p网络应用的场景，在许多地方与我们的应用有很多相似的地方，可以学习借鉴。
参考文章：
对等网络(P2P)中主流分布式哈希算法比较分析
http://www.ppcn.net/n3443c38.aspx

其他参考文章：
http://www.taiwanren.com/blog/article.asp?id=840
http://www.iwms.net/n923c43.aspx
http://tech.idv2.com/2008/07/24/memcached-004/

相关代码：
last.fm的ketama代码
http://static.last.fm/rj/ketama.tar.bz2

php版的Consistent Hashing实现：Flexihash
主页：
http://paul.annesley.cc/articles/2008/04/flexihash-consistent-hashing-php
google code上的代码主页：
http://code.google.com/p/flexihash/
现在已经移居到github上了：
http://github.com/pda/flexihash/

一致性hash算法（consistent hashing）

作者：张亮

来源：http://blog.csdn.net/sparkliang/article/details/5279393

consistent hashing算法早在1997年就在论文Consistent hashing and random trees中被提出，目前在cache系统中应用越来越广泛；

1基本场景

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

hash(object)%N

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

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

2由于访问加重，需要添加cache，这时候cache是N+1台，映射公式变成了hash(object)%(N+1)；

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

再来考虑第三个问题，由于硬件能力越来越强，你可能想让后面添加的节点多做点活，显然上面的hash算法也做不到。

有什么方法可以改变这个状况呢，这就是consistent hashing...

2 hash算法和单调性

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

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

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

3 consistent hashing算法的原理

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

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

3.1环形hash空间

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

图1环形hash空间

3.2把对象映射到hash空间

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

hash(object1) = key1;

… …

hash(object4) = key4;

图2 4个对象的key值分布

3.3把cache映射到hash空间

Consistent hashing的基本思想就是将对象和cache都映射到同一个hash数值空间中，并且使用相同的hash算法。

假设当前有A,B和C共3台cache，那么其映射结果将如图3所示，他们在hash空间中，以对应的hash值排列。

hash(cache A) = key A;

… …

hash(cache C) = key C;

图3 cache和对象的key值分布

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

3.4把对象映射到cache

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

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

依然继续上面的例子（参见图3），那么根据上面的方法，对象object1将被存储到cache A上；object2和object3对应到cache C；object4对应到cache B；

3.5考察cache的变动

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

3.5.1移除cache

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

因此这里仅需要变动对象object4，将其重新映射到cache C上即可；参见图4。

图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。

图5添加cache D后的映射关系

4虚拟节点

考量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。

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

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

objec1->cache A2；objec2->cache A1；objec3->cache C1；objec4->cache C2；

因此对象object1和object2都被映射到了cache A上，而object3和object4映射到了cache C上；平衡性有了很大提高。

引入“虚拟节点”后，映射关系就从{对象->节点}转换到了{对象->虚拟节点}。查询物体所在cache时的映射关系如图7所示。

图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

5小结

Consistent hashing的基本原理就是这些，具体的分布性等理论分析应该是很复杂的，不过一般也用不到。

http://weblogs.java.net/blog/2007/11/27/consistent-hashing上面有一个java版本的例子，可以参考。

http://blog.csdn.net/mayongzhan/archive/2009/06/25/4298834.aspx转载了一个PHP版的实现代码。

http://www.codeproject.com/KB/recipes/lib-conhash.aspxC语言版本

一些参考资料地址：

http://portal.acm.org/citation.cfm?id=258660

http://en.wikipedia.org/wiki/Consistent_hashing

http://www.spiteful.com/2008/03/17/programmers-toolbox-part-3-consistent-hashing/

http://weblogs.java.net/blog/2007/11/27/consistent-hashing

http://tech.idv2.com/2008/07/24/memcached-004/

http://blog.csdn.net/mayongzhan/archive/2009/06/25/4298834.aspx