一致性hash

     一致性哈希算法（Consistent Hashing）最早在论文《Constient Hashing and Random Trees:Distributed Caching Protocols for Relieveing Hot Spots on the World Wide Web》中被提出，前不久看了这篇论文，对于一致性hash似乎也只有个大概的了解。最近计算机网络考试考到Chord算法，似乎便用到了一致性hash，故再次查阅一致性hash的相关资料。本文目的是基于自己的理解，简明扼要的解释一致性hash的实质，阐明该算法的基本用途并说明一致性hash在实际分布式中解决雪崩效应的方式。

    分布式缓存问题

   假设有一个网站，随着流量的增加，服务器的压力越来越大，直接读取数据库的方式也变得越来越不给力，于是引入Memcached机制。假设有N台Cache服务器（后面简称Cache），那么如何将一个Object对象映射到这些Cache服务器上呢？显然最直接的策略方式便是将每一次请求随机的发送到其中一台Cache上，但这种策略带来两个问题：一是时间上，某Object对象已经被缓存，但访问没有命中。因为无法保证对同一Object对象的所有访问都能随机发送到同一台Cache上。二是空间上，同一份数据可能被缓存在多台Cache上而造成数据冗余。

    那么怎样才能解决上述问题呢，显然，只要解决好保证对同一Object对象的所有访问都能发送到同一台Cache上。这样的实现方法很多，但我们通常用的就是hash算法。对每一次访问，计算其hash值：h=Hash(Object)%N。对N台Cache进行编号0，1，2，...，N-1，然后利用hash值均匀的映射到N台Cache服务器上。

    这一策略的确解决了随机策略所带来的问题，一切都能够正常运行。然而这一策略，又引来了新的问题。考虑下面两种情况。

    1，一个Cache服务器（假设编号为m）出现宕机（在实际应用中必须要考虑这种情况），这样所有映射到 cache m 的对象都会失效，怎么办，需要把Cache m 从 N台Cache 中移除，这时Cache数量 变为 N-1 台，映射公式变成了 h=Hash(Object)%(N-1) ；

    2，由于访问加重，需要添加 Cache ，这时 Cache 数量变为 N+1 台，映射公式变成了h=hash(Object)%(N+1) ；

    若是出现上述两种情况，大量的Object被重定位到不同的服务器，这就意味几乎对任意的Object的访问，Cache都无法命中。这就导致所有的访问如洪水一般直接冲向后台服务器。

   一个良好的分布式hash方案应该具有良好的单调性：即如果已经有一些内容通过哈希分派到了相应的缓冲中，又有新的缓冲加入到系统中。哈希的结果应能够保证原有已分配的内容可以被映射到新的缓冲中去，而不会被映射到旧的缓冲集合中的其他缓冲区。而一致性hash算法就是这样的一个方案。

    一致性hash

             原理：在移除或者添加一个 Cache 时，它能够尽可能小的改变已存在 Object的映射关系，尽可能的满足单调性的要求。

      一致性hash的hash环形空间：将整个哈希值空间组织成一个虚拟的圆环，如假设某哈希函数Hash的值空间为0 - 2³²-1（即哈希值是一个32位无符号整形），整个空间按顺时针方向组织，0和2³²-1在零点中方向重合。整个哈希空间环如下图1。

                                  

                                             图1：hash环形空间

             将Cache映射到hash空间：对各个Cache服务器使用Hash函数进行一次哈希，具体可以使用服务器的ip或者名字作为关键字进行哈希，这样就能确定每台Cache服务器在hash环上的位置。假设有四台Cache服务器，使用ip地址作为关键字得到再hash环空间的位置如下图2。

                        

                                              图2：将Cache服务器哈希后的环空间

               把对象映射到hash 环空间：考虑 6个对象 Object0~Object5 ，通过 Hash 函数计算出的 hash 值 h分别为A~F，在环上的分布如下图3 所示。

                        

                                                            图3：对每一个Object进行hash

       然后分别对每个Object，从数据映射到的位置开始顺时针查找，  第一台找到的Cache服务器就是该Object应该定位到的Cache服务器，如图4。

                   

                                         图4：对每一个Object进行定位

          可以看出consistent hashing算法就是为了避免普通的hash算法处理分布式时导致机器扩展性发生严重缺陷所产生的。   

   一致性hash与雪崩效应

         何谓雪崩效应？我们以上面已经叙述的一致性hash为标准去看，如果Cache2发生宕机，那么位于Cache2的数据会被全部搬迁至Cache3，如果Cache3的磁盘空间过低，会导致数据丢失，更不敢想象的是，即使磁盘空间够，也有可能导致原本对与CacheB的大量访问访问被迁移至Cache3，如果Cache3的并发处理能力达不到要求，那么就会导致挂掉，所有的数据和并发冲入Cache0，依次类推，这就是一致性hash造成的雪崩效应。

         用来处理雪崩效应的典型方法便是利用虚拟节点。 为了解决一致性hash中，节点分布不均衡（此处可看做是Cache分布不均衡），consistent hasing引入了“虚拟节点”的概念，“虚拟节点”即实际节点在hash环空间中的复制品，对应个数称为“复制个数”，虚拟节点在hash环空间中同样以hash值排列。

           以仅部署两个Cache服务器为例，Cache0和Cache1，如图5。

                  

                                         图5：不均衡的分布

          这样的部署即Cache分布不均衡，这样的hash算法不具有良好的平衡型，也更容易出现雪崩效应。现引入“虚拟节点”，并设置“复制个数为2”。这样就有了四个虚拟节点。Cache0A和Cache0B代表了Cache0，Cache1A和Cache1B代表了Cache1。如图6。

              

                                     图6：引入虚拟节点

         通过引入虚拟节点，定位关系从{ 对象——> 实际Cache } 变为 { 对象——> 虚拟Cache }，数据定位的算法仍然保持不变，只是多了一条虚拟节点到实际节点的映射。例如定位到Cache1A和Cache1B的数据均将定位到Cache1上。这样就解决了数据倾斜的问题，从而有效的避免雪崩效应。