一致性hash问题(负载均衡原理)

一致性哈希问题

简介

一致性Hash是一种特殊的Hash算法，由于其均衡性、持久性的映射特点，被广泛的应用于负载均衡领域，如nginx和memcached都采用了一致性Hash来作为集群负载均衡的方案。

本文将介绍一致性Hash的基本思路，并讨论其在分布式缓存集群负载均衡中的应用。同时也会进行相应的代码测试来验证其算法特性，并给出和其他负载均衡方案的一些对比。

一致性Hash算法简介

在了解一致性Hash算法之前，先来讨论一下Hash本身的特点。普通的Hash函数最大的作用是散列，或者说是将一系列在形式上具有相似性质的数据，打散成随机的、均匀分布的数据。

比如，对字符串abc和abcd分别进行md5计算，得到的结果如下：

可以看到，两个在形式上非常相近的数据经过md5散列后，变成了完全随机的字符串。负载均衡正是利用这一特性，对于大量随机的请求或调用，通过一定形式的Hash将他们均匀的散列，从而实现压力的平均化。（当然，并不是只要使用了Hash就一定能够获得均匀的散列，后面会分析这一点。）

举个例子，如果我们给每个请求生成一个Key，只要使用一个非常简单的Hash算法Group = Key % N来实现请求的负载均衡，如下：

（如果将Key作为缓存的Key，对应的Group储存该Key的Value，就可以实现一个分布式的缓存系统，后文的具体例子都将基于这个场景）

不难发现，这样的Hash只要集群的数量N发生变化，之前的所有Hash映射就会全部失效。如果集群中的每个机器提供的服务没有差别，倒不会产生什么影响，但对于分布式缓存这样的系统而言，映射全部失效就意味着之前的缓存全部失效，后果将会是灾难性的。

一致性Hash通过构建环状的Hash空间代替线性Hash空间的方法解决了这个问题，如下图：

整个Hash空间被构建成一个首尾相接的环，使用一致性Hash时需要进行两次映射。

第一次，给每个节点（集群）计算Hash，然后记录它们的Hash值，这就是它们在环上的位置。

第二次，给每个Key计算Hash，然后沿着顺时针的方向找到环上的第一个节点，就是该Key储存对应的集群。

分析一下节点增加和删除时对负载均衡的影响，如下图：

可以看到，当节点被删除时，其余节点在环上的映射不会发生改变，只是原来打在对应节点上的Key现在会转移到顺时针方向的下一个节点上去。增加一个节点也是同样的，最终都只有少部分的Key发生了失效。不过发生节点变动后，整体系统的压力已经不是均衡的了，下文中提到的方法将会解决这个问题。

负载均衡的实现原理

对于上面这种情况，当一个请求进来以后，就会找它顺时针最近的一个点（也就是一个服务器），由于hash的均匀性，每个请求被均匀的分布在每台服务器上。这就实现了负载均衡。

如果要添加一个服务器m4，比如说m2和m3之间添加一个服务器，m4现在要管m2到m4之间的数据，这段数据之前是由m3管理。因此，现在m4只需要向m3要这一段数据。这样一看，添加服务器数据迁移的代价很低！

如果要删除一个服务器m4，也很简单，只需要把m4的数据交给顺时针离他最近的服务器m3。

问题与优化

最基本的一致性Hash算法直接应用于负载均衡系统，效果仍然是不理想的，存在诸多问题，下面就对这些问题进行逐个分析并寻求更好的解决方案。

数据倾斜

如果节点的数量很少，而hash环空间很大（一般是 0 ~ 2^32），直接进行一致性hash上去，大部分情况下节点在环上的位置会很不均匀（就是没法均分），挤在某个很小的区域。最终对分布式缓存造成的影响就是，集群的每个实例上储存的缓存数据量不一致，会发生严重的数据倾斜。

负载不均衡

当服务器数量很小的时候，比如说三台服务器。就算是均分在哈希环上了，当一旦添加或者删除一台服务器，立马就变得负载不均衡。就如上面的例子，m3、m4加起来才管理三分之一的数据。其他两台服务器各占三分之一。

缓存雪崩

如果每个节点在环上只有一个节点，那么可以想象，当某一集群从环中消失时，它原本所负责的任务将全部交由顺时针方向的下一个集群处理。例如，当group0退出时，它原本所负责的缓存将全部交给group1处理。这就意味着group1的访问压力会瞬间增大。设想一下，如果group1因为压力过大而崩溃，那么更大的压力又会向group2压过去，最终服务压力就像滚雪球一样越滚越大，最终导致雪崩。

引入虚拟节点

解决上述两个问题最好的办法就是扩展整个环上的节点数量，因此我们引入了虚拟节点的概念。一个实际节点将会映射多个虚拟节点，这样Hash环上的空间分割就会变得均匀。

同时，引入虚拟节点还会使得节点在Hash环上的顺序随机化，这意味着当一个真实节点失效退出后，它原来所承载的压力将会均匀地分散到其他节点上去。

如下图：