应用场景

一致性hash一般应用与数据库的分库分表，分布式缓存数据的获取等等，一般都与类似与多节点的选择这种业务有点关系，解决扩容带来的整体雪崩问题。

通过hash让数据均匀落在各个节点上

增加N个节点，为了保证数据的均匀，一般情况会采用对key值hash，然后对节点个数取模的方式，然后根据结果，确认数据落到哪台节点上。

hash(key)%N

这样数据就均匀了，但是同时带来了问题。导致数据错乱，造成几乎所有节点雪崩。

某个节点突然挂掉。节点突然从N变为N-1台。

业务的不断壮大，需要增加M个节点来应对现有的数据量。

改进方案（一致性Hash）- 通过负载均衡举例理解

分布式系统中负载均衡的问题时候可以使用Hash算法让固定的一部分请求落到同一台服务器上，这样每台服务器固定处理一部分请求（并维护这些请求的信息），起到负载均衡的作用，比如在分布式中我们需要使用到session，就要求同一个浏览器请求必须落到同一台机器上。但是普通的余数hash（hash(比如用户id)%服务器机器数）算法伸缩性很差，当新增或者下线服务器机器时候，用户id与服务器的映射关系会大量失效。一致性hash则利用hash环对其进行了改进。只是改进，同样不能避免该问题。

一致性hash

使用常见的hash算法可以把一个key值哈希到一个具有2^32个桶的空间中。也可以理解成，将key值哈希到 [0, 2^32) 的一个数字空间中。 我们假设这个是个首尾连接的环形空间。

假设我们现在有key1,key2,key3,key4 4个key值，我们通过一定的hash算法，将其对应到上面的环形hash空间中。k1=hash(key1);k2=hash(key2);k3=hash(key3);k4=hash(key4);

同样的，假设我们有3台cache服务器。把缓存服务器通过hash算法，加入到上述的环中。一般情况下是根据机器的IP地址或者唯一的计算机别名进行哈希,得到c1,c2,c3。

接下来就是数据如何存储到cache服务器上了，key值哈希之后的结果顺时针找上述环形hash空间中，距离自己最近的机器节点，然后将数据存储到上面， 如上图所示，k1 存储到 c3 服务器上， k4,k3存储到c1服务器上， k2存储在c2服务器上。用图表示如下：

假设cache3服务器宕机，这时候需要从集群中将其摘除。那么，之前存储再c3上的k1，将会顺时针寻找距离它最近的一个节点，也就是c1节点，这样，k1就会存储到c1上了，看一看下下面的图，比较清晰。

摘除c3节点之后，只影响到了原先存储再c3上的k1，而k3、k4、k2都没有受到影响，也就意味着解决了最开始的解决方案（hash(key)%N）中可能带来的雪崩问题。

增加节点和删除节点同理。

思考

为什么是2^32个桶空间？

最后

最近看到很多人在面试，我这里有一份整理过的JAVA核心知识点整理.pdf，全局知识复习必备，无论学习还是面试准备，都很全面。需要的同学，评论 + 转发后，发送私信：核心知识点。