[梁山好汉说IT] 如何理解一致性Hash

0x00 摘要

用梁山酒店分配客人为例来理解一致性Hash。

0x01. 与经典哈希方法的对比

经典哈希方法：总是假设内存位置的数量是已知且固定不变的。因为hash映射依赖节点/内存位置，所以如果需要变化集群，需要重新计算每一个key的哈希值。哈希表(服务器数量)大小的变更实际上干扰了所有映射。
一致性哈希：某种虚拟环结构。位置数量不再固定，环有无限数量的点，服务器节点可以放置在环上的随机位置。哈希表(服务器数量)大小改变会导致只有一部分请求（相对于环分配因子）会受到特定的环变更的影响。

0x02. 一致性哈希如何处理请求

如何决定哪个请求将由哪个服务器节点来处理？如果我们假设环是有序的，以便环的顺时针遍历与位置地址的递增顺序对应，那么每个请求可以由最先出现在该顺时针遍历中的那个服务器节点来处理。

也就是说，地址高于请求地址的第一个服务器节点负责处理该请求。如果请求地址高于最高寻址节点，它由最小地址的服务器节点来处理，因为环遍历以圆形方式进行。

从理论上来说，每个服务器节点“拥有”哈希环的一个区间，进入该区间的任何请求将由同一服务器节点来处理。

现在，如果其中一个服务器节点出现故障，下一个服务器节点的区间就变宽，进入该区间的任何请求都将进入到新的服务器节点，该怎么办？那就需要重新分配的是仅仅这一个区间（与出现故障的服务器节点对应），哈希环的其余部分和请求/节点分配仍然不受影响。

0x03. 一致性哈希的关键点：

按照常用的hash算法来将对应的key哈希到一个具有2^32次方个桶的空间中，即0 ~（2^32）-1的数字空间。我们可以将这些数字头尾相连，想象成一个闭合的环形。

这个就是关键点，就是部署服务器的时候，服务器的序号空间已经是1~2^32。服务器可以分配1~2^32中任一序号。

0x04. 梁山如何处理

经典算法：

梁山4个酒店，按照顺序其序号是1，2，3，4。这个1~4序号就是固定的，不能修改的。

哈希函数：客人姓名笔画/4，按照余数分配到这4个酒店中。

如果减少一个酒店，则客人按照姓名笔画/3，都得重新分配酒店

如果增加一个酒店，则客人按照姓名笔画/5，都得重新分配酒店

一致性算法：

预先就把服务器的序号空间(现在~未来)想好了，定为100个桶。就是在未来可见的年份内，100个肯定够了。

哈希函数：客人姓名笔画/100.

酒店/客人分配规则如下：

酒店1负责 hash(x)--> 1~20，即客人姓名笔画/100位于1~20之间。
酒店2负责 hash(x)--> 21~40，
酒店3负责 hash(x)--> 41~60，
酒店4负责 hash(x)--> 61~100，

客人住店规则如下：

a. 客人来了，姓氏笔画/100，得到余数。去余数对应的酒店住。比如余数3住到酒店1，余数22则住到酒店2......
b. 如果该酒店出问题关门了，就去比所有 "比余数大的酒店" 中最小那个住。以此类推。比如酒店1挂了，就去酒店2，酒店2挂了去3。
c. 如果最大酒店也出问题关门了，就转圈回到最小酒店住。即如果酒店4挂了去酒店1.

异常处理：

减少酒店。如果酒店3挂了，则原来去酒店3的客人去酒店4，原来去酒店4的客人还是酒店4. 这样只有酒店4受到影响，1，2号酒店客人不用搬家。
增加酒店。如果增加了一个酒店5.则需要对酒店/客人分配规则做改变。让4号酒店负责61~80，5号酒店负责81~100。这样4号点原有部分客人要迁移到5号。

关键点：

可以看出来，关键在于服务器的序号空间早就确定了是一个大数字100。当然这是梁山。对于其他真实案例可能是2^32。

具体分配酒店的算法，是可以融入到hash中。即酒店号码可能就是21，41，61....

0x05. 参考

https://blog.csdn.net/gerryke/article/details/53939212

https://blog.csdn.net/cb_lcl/article/details/81448570

https://www.iteblog.com/archives/2499.html

http://www.zsythink.net/archives/1182/

https://www.sohu.com/a/239283928_463994