一致性哈希算法在1997年由麻省理工学院提出的一种分布式哈希(DHT)实现算法,设计目标是为了解决因特网中的热点(Hot spot)问题,初衷和CARP十分类似。一致性哈希修正了CARP使用的简 单哈希算法带来的问题,使得分布式哈希(DHT)可以在P2P环境中真正得到应用。
一致性hash算法提出了在动态变化的Cache环境中,判定哈希算法好坏的四个定义:
1、平衡性(Balance):平衡性是指哈希的结果能够尽可能分布到所有的缓冲中去,这样可以使得所有的缓冲空间都得到利用。很多哈希算法都能够满足这一条件。
2、单调性(Monotonicity):单调性是指如果已经有一些内容通过哈希分派到了相应的缓冲中,又有新的缓冲加入到系统中。哈希的结果应能够保证原有已分配的内容可以被映射到原有的或者新的缓冲中去,而不会被映射到旧的缓冲集合中的其他缓冲区。
3、分散性(Spread):在分布式环境中,终端有可能看不到所有的缓冲,而是只能看到其中的一部分。当终端希望通过哈希过程将内容映射到缓冲上时,由于不同终端所见的缓冲范围有可能不同,从而导致哈希的结果不一致,最终的结果是相同的内容被不同的终端映射到不同的缓冲区中。这种情况显然是应该避免的,因为它导致相同内容被存储到不同缓冲中去,降低了系统存储的效率。分散性的定义就是上述情况发生的严重程度。好的哈希算法应能够尽量避免不一致的情况发生,也就是尽量降低分散性。
4、负载(Load):负载问题实际上是从另一个角度看待分散性问题。既然不同的终端可能将相同的内容映射到不同的缓冲区中,那么对于一个特定的缓冲区而言,也可能被不同的用户映射为不同 的内容。与分散性一样,这种情况也是应当避免的,因此好的哈希算法应能够尽量降低缓冲的负荷。
在分布式集群中,对机器的添加删除,或者机器故障后自动脱离集群这些操作是分布式集群管理最基本的功能。如果采用常用的hash(object)%N算法,那么在有机器添加或者删除后,很多原有的数据就无法找到了,这样严重的违反了单调性原则。接下来主要讲解一下一致性哈希算法是如何设计的:
环形Hash空间
按照常用的hash算法来将对应的key哈希到一个具有2^32次方个桶的空间中,即0~(2^32)-1的数字空间中。现在我们可以将这些数字头尾相连,想象成一个闭合的环形。如下图
把数据通过一定的hash算法处理后映射到环上
现在我们将object1、object2、object3、object4四个对象通过特定的Hash函数计算出对应的key值,然后散列到Hash环上。如下图:
Hash(object1) = key1;
Hash(object2) = key2;
Hash(object3) = key3;
Hash(object4) = key4;

将机器通过hash算法映射到环上
在采用一致性哈希算法的分布式集群中将新的机器加入,其原理是通过使用与对象存储一样的Hash算法将机器也映射到环中(一般情况下对机器的hash计算是采用机器的IP或者机器唯一的别名作为输入值),然后以顺时针的方向计算,将所有对象存储到离自己最近的机器中。
假设现在有NODE1,NODE2,NODE3三台机器,通过Hash算法得到对应的KEY值,映射到环中,其示意图如下:
Hash(NODE1) = KEY1;
Hash(NODE2) = KEY2;
Hash(NODE3) = KEY3;

通过上图可以看出对象与机器处于同一哈希空间中,这样按顺时针转动object1存储到了NODE1中,object3存储到了NODE2中,object2、object4存储到了NODE3中。在这样的部署环境中,hash环是不会变更的,因此,通过算出对象的hash值就能快速的定位到对应的机器中,这样就能找到对象真正的存储位置了。
机器的删除与添加
普通hash求余算法最为不妥的地方就是在有机器的添加或者删除之后会照成大量的对象存储位置失效,这样就大大的不满足单调性了。下面来分析一下一致性哈希算法是如何处理的。
1. 节点(机器)的删除
以上面的分布为例,如果NODE2出现故障被删除了,那么按照顺时针迁移的方法,object3将会被迁移到NODE3中,这样仅仅是object3的映射位置发生了变化,其它的对象没有任何的改动。如下图:

2. 节点(机器)的添加
如果往集群中添加一个新的节点NODE4,通过对应的哈希算法得到KEY4,并映射到环中,如下图:

通过按顺时针迁移的规则,那么object2被迁移到了NODE4中,其它对象还保持这原有的存储位置。通过对节点的添加和删除的分析,一致性哈希算法在保持了单调性的同时,还是数据的迁移达到了最小,这样的算法对分布式集群来说是非常合适的,避免了大量数据迁移,减小了服务器的的压力。
平衡性
根据上面的图解分析,一致性哈希算法满足了单调性和负载均衡的特性以及一般hash算法的分散性,但这还并不能当做其被广泛应用的原由,因为还缺少了平衡性。下面将分析一致性哈希算法是如何满足平衡性的。hash算法是不保证平衡的,如上面只部署了NODE1和NODE3的情况(NODE2被删除的图),object1存储到了NODE1中,而object2、object3、object4都存储到了NODE3中,这样就照成了非常不平衡的状态。在一致性哈希算法中,为了尽可能的满足平衡性,其引入了虚拟节点。
——“虚拟节点”( virtual node )是实际节点(机器)在 hash 空间的复制品( replica ),一实际个节点(机器)对应了若干个“虚拟节点”,这个对应个数也成为“复制个数”,“虚拟节点”在 hash 空间中以hash值排列。
以上面只部署了NODE1和NODE3的情况(NODE2被删除的图)为例,之前的对象在机器上的分布很不均衡,现在我们以2个副本(复制个数)为例,这样整个hash环中就存在了4个虚拟节点,最后对象映射的关系图如下:
根据上图可知对象的映射关系:object1->NODE1-1,object2->NODE1-2,object3->NODE3-2,object4->NODE3-1。通过虚拟节点的引入,对象的分布就比较均衡了。那么在实际操作中,正真的对象查询是如何工作的呢?对象从hash到虚拟节点到实际节点的转换如下图:
“虚拟节点”的hash计算可以采用对应节点的IP地址加数字后缀的方式。例如假设NODE1的IP地址为192.168.1.100。引入“虚拟节点”前,计算 cache A 的 hash 值:
Hash(“192.168.1.100”);
引入“虚拟节点”后,计算“虚拟节”点NODE1-1和NODE1-2的hash值:
Hash(“192.168.1.100#1”); // NODE1-1
Hash(“192.168.1.100#2”); // NODE1-2
几天看了几遍一致性哈希的文章,但是都没有比较完整的实现,因此试着实现了一下,这里我就不讲一致性哈希的原理了,网上很多,以一致性哈希用在负载均衡的实例来说,一致性哈希就是先把主机ip从小大到全部放到一个环内,然后客户端ip来连接的时候,把客户端ip连接到大小最接近客户端ip且大于客户端ip的主机。当然,这里的ip一般都是要先hash一下的。我的程序运行结果如下:
- 添加客户端,一开始有4个主机,分别为s1,s2,s3,s4,每个主机有100个虚拟主机:
- 101客户端(hash:-3872430075274208315)连接到主机->s2-192.168.1.2
- 102客户端(hash:-6461488502093916753)连接到主机->s1-192.168.1.1
- 103客户端(hash:-3272337528088901176)连接到主机->s3-192.168.1.3
- 104客户端(hash:7274050343425899995)连接到主机->s2-192.168.1.2
- 105客户端(hash:6218187750346216421)连接到主机->s1-192.168.1.1
- 106客户端(hash:-8497989778066313989)连接到主机->s2-192.168.1.2
- 107客户端(hash:2219601794372203979)连接到主机->s3-192.168.1.3
- 108客户端(hash:1903054837754071260)连接到主机->s3-192.168.1.3
- 109客户端(hash:-2425484502654523425)连接到主机->s1-192.168.1.1
- 删除主机s2-192.168.1.2的变化:
- hash(-8497989778066313989)改变到->s4-192.168.1.4
- hash(7274050343425899995)改变到->s2-192.168.1.2
- hash(-3872430075274208315)改变到->s4-192.168.1.4
- hash(7274050343425899995)改变到->s1-192.168.1.1
- 增加主机s5-192.168.1.5的变化:
- hash(1903054837754071260)改变到->s5-192.168.1.5
- hash(1903054837754071260)改变到->s5-192.168.1.5
- hash(-3272337528088901176)改变到->s5-192.168.1.5
- 最后的客户端到主机的映射为:
- hash(-8497989778066313989)连接到主机->s4-192.168.1.4
- hash(-6461488502093916753)连接到主机->s1-192.168.1.1
- hash(-3872430075274208315)连接到主机->s4-192.168.1.4
- hash(-3272337528088901176)连接到主机->s5-192.168.1.5
- hash(-2425484502654523425)连接到主机->s1-192.168.1.1
- hash(1903054837754071260)连接到主机->s5-192.168.1.5
- hash(2219601794372203979)连接到主机->s3-192.168.1.3
- hash(6218187750346216421)连接到主机->s1-192.168.1.1
- hash(7274050343425899995)连接到主机->s1-192.168.1.1
看结果可知:一开始添加到9个客户端,连接到主机s1,s2,s3,s4的客户端分别有3,3,3,0个,经过删除主机s2,添加主机s5,最后9个客户端分别连接到主机s1,s2,s3,s4,s5的个数为4,0,1,2,2.这里要说明一下删除主机s2的情况,hash尾号为9995的客户端先连接到s2,再连接到s1,为什么会出现这种情况呢?因为每一个真实主机有n个虚拟主机,删除s2却打印“hash(7274050343425899995)改变到->s2-192.168.1.2”是因为删除了s2的其中一个虚拟主机,跳转到另一个虚拟主机,但还是在s2上,当然,这里是打印中间情况,以便了解,真实的环境是删除了s2后,所有他的虚拟节点都会马上被删除,虚拟节点上的连接也会重新连接到另一个主机的虚拟节点,不会存在这种中间情况。
以下给出所有的实现代码,大家共同学习:
- public class Shard<Node> {
-
- static private TreeMap<Long, Node> nodes;
- static private TreeMap<Long,Node> treeKey;
- static private List<Node> shards = new ArrayList<Node>();
- private final int NODE_NUM = 100;
- boolean flag = false;
-
- public Shard(List<Node> shards) {
- super();
- this.shards = shards;
- init();
- }
-
- public static void main(String[] args) {
-
-
-
- Node s1 = new Node("s1", "192.168.1.1");
- Node s2 = new Node("s2", "192.168.1.2");
- Node s3 = new Node("s3", "192.168.1.3");
- Node s4 = new Node("s4", "192.168.1.4");
- Node s5 = new Node("s5","192.168.1.5");
- shards.add(s1);
- shards.add(s2);
- shards.add(s3);
- shards.add(s4);
- Shard<Node> sh = new Shard<Shard.Node>(shards);
- System.out.println("添加客户端,一开始有4个主机,分别为s1,s2,s3,s4,每个主机有100个虚拟主机:");
- sh.keyToNode("101客户端");
- sh.keyToNode("102客户端");
- sh.keyToNode("103客户端");
- sh.keyToNode("104客户端");
- sh.keyToNode("105客户端");
- sh.keyToNode("106客户端");
- sh.keyToNode("107客户端");
- sh.keyToNode("108客户端");
- sh.keyToNode("109客户端");
-
- sh.deleteS(s2);
-
-
- sh.addS(s5);
-
- System.out.println("最后的客户端到主机的映射为:");
- printKeyTree();
- }
- public static void printKeyTree(){
- for(Iterator<Long> it = treeKey.keySet().iterator();it.hasNext();){
- Long lo = it.next();
- System.out.println("hash("+lo+")连接到主机->"+treeKey.get(lo));
- }
-
- }
-
- private void init() {
- nodes = new TreeMap<Long, Node>();
- treeKey = new TreeMap<Long, Node>();
- for (int i = 0; i != shards.size(); ++i) {
- final Node shardInfo = shards.get(i);
-
- for (int n = 0; n < NODE_NUM; n++)
-
- nodes.put(hash("SHARD-" + shardInfo.name + "-NODE-" + n), shardInfo);
- }
- }
-
- private void addS(Node s) {
- System.out.println("增加主机"+s+"的变化:");
- for (int n = 0; n < NODE_NUM; n++)
- addS(hash("SHARD-" + s.name + "-NODE-" + n), s);
-
- }
-
-
- public void addS(Long lg,Node s){
- SortedMap<Long, Node> tail = nodes.tailMap(lg);
- SortedMap<Long,Node> head = nodes.headMap(lg);
- Long begin = 0L;
- Long end = 0L;
- SortedMap<Long, Node> between;
- if(head.size()==0){
- between = treeKey.tailMap(nodes.lastKey());
- flag = true;
- }else{
- begin = head.lastKey();
- between = treeKey.subMap(begin, lg);
- flag = false;
- }
- nodes.put(lg, s);
- for(Iterator<Long> it=between.keySet().iterator();it.hasNext();){
- Long lo = it.next();
- if(flag){
- treeKey.put(lo, nodes.get(lg));
- System.out.println("hash("+lo+")改变到->"+tail.get(tail.firstKey()));
- }else{
- treeKey.put(lo, nodes.get(lg));
- System.out.println("hash("+lo+")改变到->"+tail.get(tail.firstKey()));
- }
- }
- }
-
-
- public void deleteS(Node s){
- if(s==null){
- return;
- }
- System.out.println("删除主机"+s+"的变化:");
- for(int i=0;i<NODE_NUM;i++){
-
- SortedMap<Long, Node> tail = nodes.tailMap(hash("SHARD-" + s.name + "-NODE-" + i));
- SortedMap<Long,Node> head = nodes.headMap(hash("SHARD-" + s.name + "-NODE-" + i));
- Long begin = 0L;
- Long end = 0L;
-
- SortedMap<Long, Node> between;
- if(head.size()==0){
- between = treeKey.tailMap(nodes.lastKey());
- end = tail.firstKey();
- tail.remove(tail.firstKey());
- nodes.remove(tail.firstKey());
- flag = true;
- }else{
- begin = head.lastKey();
- end = tail.firstKey();
- tail.remove(tail.firstKey());
- between = treeKey.subMap(begin, end);
- flag = false;
- }
- for(Iterator<Long> it = between.keySet().iterator();it.hasNext();){
- Long lo = it.next();
- if(flag){
- treeKey.put(lo, tail.get(tail.firstKey()));
- System.out.println("hash("+lo+")改变到->"+tail.get(tail.firstKey()));
- }else{
- treeKey.put(lo, tail.get(tail.firstKey()));
- System.out.println("hash("+lo+")改变到->"+tail.get(tail.firstKey()));
- }
- }
- }
-
- }
-
-
- public void keyToNode(String key){
- SortedMap<Long, Node> tail = nodes.tailMap(hash(key));
- if (tail.size() == 0) {
- return;
- }
- treeKey.put(hash(key), tail.get(tail.firstKey()));
- System.out.println(key+"(hash:"+hash(key)+")连接到主机->"+tail.get(tail.firstKey()));
- }
-
-
-
-
-
-
-
- private static Long hash(String key) {
-
- ByteBuffer buf = ByteBuffer.wrap(key.getBytes());
- int seed = 0x1234ABCD;
-
- ByteOrder byteOrder = buf.order();
- buf.order(ByteOrder.LITTLE_ENDIAN);
-
- long m = 0xc6a4a7935bd1e995L;
- int r = 47;
-
- long h = seed ^ (buf.remaining() * m);
-
- long k;
- while (buf.remaining() >= 8) {
- k = buf.getLong();
-
- k *= m;
- k ^= k >>> r;
- k *= m;
-
- h ^= k;
- h *= m;
- }
-
- if (buf.remaining() > 0) {
- ByteBuffer finish = ByteBuffer.allocate(8).order(
- ByteOrder.LITTLE_ENDIAN);
-
-
- finish.put(buf).rewind();
- h ^= finish.getLong();
- h *= m;
- }
-
- h ^= h >>> r;
- h *= m;
- h ^= h >>> r;
-
- buf.order(byteOrder);
- return h;
- }
-
- static class Node{
- String name;
- String ip;
- public Node(String name,String ip) {
- this.name = name;
- this.ip = ip;
- }
- @Override
- public String toString() {
- return this.name+"-"+this.ip;
- }
- }
-
- }
http://blog.csdn.net/haitao111313/article/details/7537799
参考:
http://blog.csdn.net/wuhuan_wp/article/details/7010071
参考:
http://blog.csdn.net/cywosp/article/details/23397179/
|