分布式缓存散列存储示意图
前面我们介绍过各种散列方法，不管是选择上述哪种散列方法，在这个应用场景下，都是要把缓存数据利用哈希函数均匀的映射到服务器集群上，我们就选择简单的「取模法」来说明这个过程。
假设有 3 个服务器节点编号 [0 - 2]，6 个缓存键值对编号 [1 - 6]，则完成哈希映射之后，三个缓存数据映射情况如下：
哈希计算公式：key % 节点总数 = Hash节点下标
1 % 3 = 1
2 % 3 = 2
3 % 3 = 0
4 % 3 = 1
5 % 3 = 2
6 % 3 = 0
缓存哈希实例
每个连接都均匀的分散到了三个不同的服务器节点上，看起来很完美！
但是，在分布式集群系统的负载均衡实现上，这种模型有两个问题：
1. 扩展能力差为了动态调节服务能力，服务节点经常需要扩容缩容。打个比方，如果是电商服务，双十一期间的服务机器数量肯定要比平常大很多，新加进来的机器会使原来计算的哈希值不准确，为了达到负载均衡的效果，要重新计算并更新哈希值，对于更新后哈希值不一致的缓存数据，要迁移到更新后的节点上去。
假设新增了 1 个服务器节点，由原来的 3 个服务节点变成 4 个节点编号 [0 - 3]，哈希映射情况如下：
哈希计算公式：key % 节点总数 = Hash节点下标
1 % 4 = 1
2 % 4 = 2
3 % 4 = 3
4 % 4 = 0
5 % 4 = 1
6 % 4 = 2
可以看到后面三个缓存 key ：4、5、6 对应的存储节点全部失效了，这就需要把这几个节点的缓存数据迁移到更新后的节点上 (费时费力) ，也就是由原来的节点 [1, 2, 0] 迁移到节点 [0, 1, 2]，迁移后存储示意图如下：
缓存哈希扩展性示意图
线上环境服务节点虽然有各种高可用性保证，但还是是有宕机的可能，即使没有宕机也有缩容的需求。不管是宕机和缩容都可以归结为服务节点删除的情况，下面分析下服务节点删除对负载均衡哈希值的影响。
假设删除 1 个服务器节点，由最初的 3 个服务节点变成 2 个，节点编号 [0 - 1]，哈希映射情况如下：
哈希计算公式：key % 节点总数 = Hash节点下标
1 % 2 = 1
2 % 2 = 0
3 % 2 = 1
4 % 2 = 0
5 % 2 = 1
6 % 2 = 0
下图展示普通哈希负载均衡算法在一个节点宕机时候，导致的的缓存数据迁移分布情况：
缓存哈希容错性示意图
如图所见，在这个例子中，仅仅删除了一个服务节点，也导致了哈希值的大面积更新，哈希值的更新也是意味着节点缓存数据的迁移（缓存数据表示心好累）。
一致性哈希算法负载均衡正是由于普通哈希算法实现的缓存负载均衡存在扩展能力和容错能力差问题，所以我们引入一致性哈希算法，那么什么是一致性哈希呢？先来看下wiki上对一致性Hash的定义
一致哈希由 MIT 的 David Karger 及其合作者提出，现在这一思想已经扩展到其它领域。在这篇1997年发表的学术论文中介绍了一致哈希如何应用于用户易变的分布式Web服务中。一致哈希也可用于实现健壮缓存来减少大型Web应用中系统部分失效带来的负面影响。
这篇描述一致性哈希的论文发表于1997年，阅读无障碍的同学可以直接看看大佬的论文理解更深刻，附上论文下载链接：http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.147.1879
