谈谈对一致性Hash算法的理解

一、前言

一致性hash算法是分布式系统常用的算法，也是面试必问的算法，相信很多朋友对这个算法还比较陌生，本文谈一谈我对Hash一致性算法的理解。

二、问题引申

在正式开启主题之前，我先描述一个场景，大家可以想想思考下如果是你，会怎么解决这个问题。

场景描述： 

某小型网站618大促监控，运维发现领券接口4台服务器，某1台服务器的负载压力很大，大部分的用户请求都打在了其中1台服务器。如果让你来避免这个问题，让每台服务器均匀的处理一些请求， 你会怎么做？

我们首先想到的是，我们可以对用户的会员编号（全局唯一）进行hash，并将hash后的结果对服务器的数量进行取模，即 hash(用户id)% 4，这样得到的结果一定是0、1/、2、3，即分别对应4条服务器。但是这样存在一个问题，当系统扩容增加1台服务器时，取模算法变成了 hash(用户id)% 5，当系统故障减少1台服务器时，取模算法变成 hash(用户id)% 3 ，可以看到，当服务器数量增加或减少时，取模算法发生了改变，所有的请求也都需要重新分配服务器，显然这种做法不合理。

这种方法对应的是经典hash算法，即总是假设内存位置的数量是已知且固定不变的。因为hash映射依赖节点/内存位置，所以如果需要变化集群，需要重新计算每一个key的哈希，实质干扰了所有的节点内存映射关系。

为了解决这个问题，我们可以使用另外一种方法，首先计算四个ip地址对应的hash值，如hash(ip1)、hash(ip2)、hash(ip3)、hash(ip4)，计算出的hash值是0~2^32的值， 这4个值在hash环上呈现如图：

• hash环上顺时针从整数0开始，一直到最大正整数，我们根据四个ip计算的hash值肯定会落到这个hash环上的某一个点，至此我们把服务器的四个ip映射到了一致性hash环

• 当用户在客户端进行请求时候，首先根据hash(用户id)计算路由规则（hash值），然后看hash值落到了hash环的那个地方，根据hash值在hash环上的位置顺时针找距离最近的ip作为路由ip.

如上图可知user1,user2的请求会落到服务器ip2进行处理，user3的请求会落到服务器ip3进行处理，user4的请求会落到服务器ip4进行处理，user5,user6的请求会落到服务器ip1进行处理。

下面考虑当ip2的服务器挂了的时候会出现什么情况？
当ip2的服务器挂了的时候，一致性hash环大致如下图：

根据顺时针规则可知user1,user2的请求会被服务器ip3进行处理，而其它用户的请求对应的处理服务器不变，也就是只有之前被ip2处理的一部分用户的映射关系被破坏了，并且其负责处理的请求被顺时针下一个节点委托处理。

下面考虑当新增机器的时候会出现什么情况？
当新增一个ip5的服务器后，一致性hash环大致如下图：

根据顺时针规则可知之前user5的请求应该被ip1服务器处理，现在被新增的ip5服务器处理，其他用户的请求处理服务器不变，也就是新增的服务器顺时针最近的服务器的一部分请求会被新增的服务器所替代。

这种方法，叫一致性Hash算法，即按照常用的Hash算法来将key哈希到一个具有2^32个桶的空间内，即0~2^32-1的数字空间内，我们可以将这些数字首尾相连，想象成一个闭合的空间，即每个服务器拥有hash环的一个区间，进入该区间的任何请求将由hash环处理，我们假设hash环是有序的，顺时针旋转，请求将会落到顺时针遇到的第一个服务器节点。

这样看着似乎没问题了，但是真的是这样吗？

当服务器节点比较少的时候，假设只有3台服务器ip1，ip2，ip3，很可能请求绝大多数落到ip1服务器上，而ip2、ip3只有少部分请求，如下图，虽然每个服务器都在处理请求，但明显每个机器负载不均衡，这个现象就是hash倾斜问题。

这个问题的解决方案，一个方法是增加服务器节点个数，但是不能无限制的增加，常用的方法是增加虚拟节点。

何为虚拟节点？“虚拟节点”（ virtual node ）是实际节点在 hash 空间的复制品（ replica ），一实际个节点对应了若干个“虚拟节点”，这个对应个数也成为“复制个数”，“虚拟节点”在 hash 空间中以 hash 值排列。

如图，ip1-1是ip1的虚拟节点，ip2-1是ip2的虚拟节点，ip3-1是ip3的虚拟节点，user1、user2请求将会被ip3处理，user3请求将会被ip1处理，user4、user5被ip3处理，user6被ip1处理，均匀一致性hash的目标是如果服务器有N台，客户端的hash值有M个，那么每个服务器应该处理大概M/N个用户的。也就是每台服务器负载尽量均衡

三、一致性Hash算法的特性

考虑到分布式系统每个节点都有可能失效，并且新的节点很可能动态的增加进来，如何保证当系统的节点数目发生变化时仍然能够对外提供良好的服务，这是值得考虑的，尤其实在设计分布式缓存系统时，如果某台服务器失效，对于整个系统来说如果不采用合适的算法来保证一致性，那么缓存于系统中的所有数据都可能会失效（即由于系统节点数目变少，客户端在请求某一对象时需要重新计算其hash值（通常与系统中的节点数目有关），由于hash值已经改变，所以很可能找不到保存该对象的服务器节点），因此一致性hash就显得至关重要。

良好的分布式cahce系统中的一致性hash算法应该满足以下几个方面：

• 单调性(Monotonicity)：单调性是指如果已经有一些请求通过哈希分派到了相应的服务器进行处理，又有新的服务器加入到系统中时候，应保证原有的请求可以被映射到原有的或者新的服务器中去，而不会被映射到原来的其它服务器上去。

• 分散性(Spread)：分布式环境中，客户端请求时候可能不知道所有服务器的存在，可能只知道其中一部分服务器，在客户端看来他看到的部分服务器会形成一个完整的hash环。如果多个客户端都把部分服务器作为一个完整hash环，那么可能会导致，同一个用户的请求被路由到不同的服务器进行处理。这种情况显然是应该避免的，因为它不能保证同一个用户的请求落到同一个服务器。所谓分散性是指上述情况发生的严重程度。好的哈希算法应尽量避免尽量降低分散性。 一致性hash具有很低的分散性

• 平衡性(Balance)：平衡性也就是说负载均衡，是指客户端hash后的请求应该能够分散到不同的服务器上去。一致性hash可以做到每个服务器都进行处理请求，但是不能保证每个服务器处理的请求的数量大致相同。

• 负载(Load)：负载问题实际上是从另一个角度看待分散性问题。既然不同的终端可能将相同的内容映射到不同的缓冲区中，那么对于一个特定的缓冲区而言，也可能被不同的用户映射为不同的内容。与分散性一样，这种情况也是应当避免的，因此好的哈希算法应能够尽量降低缓冲的负荷。

• 平滑性(Smoothness)：平滑性是指缓存服务器的数目平滑改变和缓存对象的平滑改变是一致的。

 

参考链接：

什么是一致性Hash算法？

深入浅出一致性Hash原理