一致性 Hash 学习与实现
普通的 Hash 解决的是什么问题？
下图是一个普通的余数法构造的哈希表。
SRE实战 互联网时代守护先锋，助力企业售后服务体系运筹帷幄！一键直达领取阿里云限量特价优惠。
一般在编程中使用哈希表，某个 bucket 突然就没了的概率比较小，常见的是因为负载因子太大需要增加 bucket，然后 rehash。
考虑在上图中，2 号 bucket 突然就没了会发生什么情形。
最直接的做法就是，后面的 bucket 依次往前面补位，然后重新计算 key 的 hash 值。
2 号 bucket 虽然只存放了一个 key，但是由于 2 号 bucket 的丢失，导致后面所有 bucket 存放的 key 的映射关系都失效了。
如果这个 hash 表在内存中，无非就是 rehash 一下，重新建立对应关系，问题不大。
但如果这种情况发生在分布式缓存中呢？这会导致大量的缓存失效，有可能导致很多请求直接冲到后端。
想想看，本来想用分布式缓存扛流量，结果仅仅因为其中一台缓存服务器挂掉了而导致整个缓存系统不可用，太脆弱了。
问题在于：每一个 key 映射到 bucket 的规则太精确了，完全没有余地，每个 bucket 挨得太密。对 key 计算完后的 hash 值直接指向了 bucket。
我是这么理解的，这种 Hash 表就好像多米诺骨牌，只要把其中的一块推倒，那么直接到后面的多米诺骨牌都倒了（对应的就是映射关系全失效了）。
一致性 Hash 是怎么解决这个问题的呢？
1997 年，麻省理工学院（MIT）的 David Karger 等 6 个人发布学术论文：
《Consistent hashing and random trees: distributed caching protocols for relieving hot spots on the World Wide Web》
中文翻译就是：一致性哈希和随机树：用于缓解万维网上热点的分布式缓存协议。
我想用我的理解来讲，接上面提到的看法是，这些 bucket 都挨得太紧密了，那这样得话，我何不就把每个 bucket 的距离搞得足够长呢？
原来 Hash 表的长度可能是 57，103，947，或者 2053 这种质数。
这次我玩一把大的，直接 Hash 表的长度是 2^32-1，然后把桶分布在这个上面，大概长这样：
我不太喜欢用环来描述，脑子不太好使，还是用最简单的数组描述把。
虽然这个一致性 Hash 表很长，但是真正用来装数据的 bucket 不多，bucket 通过 hash 算法（方法有很多）能均匀分布到这个很长的数组中。
一个 key 准备存取或者查找的过程是这样的：
怎么样，是不是很简单？不过事情还没完。
这样的好处就是，bucket 之间是隔离开的，增加或者减少 bucket 只会对局部有影响，不会影响到全局，具体自己去分析吧。
一致性 Hash 倾斜的问题
如果说实际的 bucket 本来就很少呢？这样会导致大量的键和某个 bucket 建立映射，key 分布不均匀。
这里的解决方法挺厉害的，就是虚拟 bucket，也就是我一个实际的 bucket 可以虚拟出很多个 bucket 来，那么这些虚拟的 bucket 只是名字和实际 bucket 不一样。
然后虚拟节点也会挂在 Hash 表中，类似这样的：
虚拟出来的节点越多，key 的分布越均匀。
总结
1. 隔离不同的 bucket，bucket 的增加或者减少只对局部有影响
2. 虚拟节点解决 key 分布不均匀
算法没有思想重要！
我想看了上面这些，应该可以自己写一个简单版的 Consistent Hash 了。下次我写个很 low 逼的给你们看看。
