首先给个总结：
一致性xsdhb算法通过将xsdhb空间划分为1-2^32-1圆环，将cache节点和我们的对象数据的hash运算分别映射到圆环上，将对象的数据顺时针映射到一个cache 这具有的优点是，即使添加或删除节点，也只会影响相邻数据的更改，当然，一致的xsdhb存在xsdhb倾斜问题，可能会导致数据倾斜和缓存雪崩。 通过部署虚拟节点，在虚拟节点xsdhb之后获得实际节点，可以解决这个问题。 在理解背景一致的哈希算法之前，让我们先研究一下哈希本身的特点。 普通哈希函数的最大作用是将哈希，或者形式上具有相似性质的一系列数据分解为随机均匀分布的数据。
例如，有3个0、1、2号服务器，Hash以后取其馀数，则分别存在于对应的节点上。 (之所以有0，是为了在余数为0时能够识别) ) ) ) ) ) ) ) ) ) ) ) ) ) ) ) ) ) ) ) )。
目前有4个redis server节点，20个数据。
留出余地，分配节点
现在，在生产环境中突然发现redis节点不够了，需要添加节点。 或者，我们发现redis群集的负载非常低。 为了节约资源，可以删除一些节点。 添加redis节点吧
扩展后，我们发现原来的1、2、3、20这4个数据仍然保留在原来的节点上。 也就是说，redis0命中20次，redis1命中1次，redis2命中2次，redis3命中3次，命中率为4/20=20%。 这里的数据量太小，不明显，具体请看下面的公式进行说明。 一致的xsdhb
一致性Hash是一种特殊的Hash算法，由于其均衡性、持久性的映射特点，广泛应用于负载均衡领域，如nginx和memcached均采用一致性Hash作为集群负载均衡方案。
首先，让我们理解环状的hash空间。 通常，hash算法将value映射到32位key值。 将数值轴舍入为前后相连的环，取值范围0 - 2^32-1。 这表示可以存储0到2^32-1之间的数字的位置，并将对象映射到环形散列空间
我们现在有四个Object对象。 对象1、2、3和4先取散列，然后映射到散列空间。
然后cache也映射到同一个散列空间。 关于cache的计算。 可以使用cache计算机的IP地址、计算机名称等作为散列输入，也可以引入端口号等更多因子。
已将cache映射到散列环空间。 接下来需要考虑的是如何将对象映射到cache上。 在该循环空间中，例如从key1顺时针碰到最初cache节点时成为key A (即cache A )，则key1被收纳在蓝色的key A节点中，两者的散列都被固定，因此key1被收纳在cache A中因此，key1、2、3、4顺时针找到cache节点后：
当需要删除或添加缓存节点时，传统的hash算法这种取模方式会对后台服务器产生很大的冲击，很多缓存无法命中。 如果业务代码是透明的，它就会通过缓存直接攻击数据库，并很容易破坏数据库。 接下来，我们来看看一致性哈希算法的精髓。 删除cacheB时，key4(Objecy4)会顺时针找到cache c并访问cache c。 可以看到，删除cache c不会影响object2、3。 影响的是cache c从逆时针方向到object 4的范围。 影响范围很小。 以上模具的取法不会有很大的变动。
添加cache只会导致添加的cache影响第一个逆时针对象：
Hash倾斜性：问题与优化
实际上，如果cache的分布不那么均匀，a的负荷可能会变高。
数据倾斜
如果节点数量少、散列循环空间大(一般为0￣2￣32 )，则一致的散列提升在大多数情况下会导致节点在循环上的位置不均匀。
挤在某个很小的区域。最终对分布式缓存造成的影响就是，集群的每个实例上储存的缓存数据量不一致，会发生严重的数据（hash）倾斜。缓存雪崩
如果每个节点在环上只有一个节点，那么可以想象，当某一集群从环中消失时，它原本所负责的任务将全部交由顺时针方向的下一个集群处理。例如，当cache0退出时，它原本所负责的缓存将全部交给cache1处理。这就意味着cache1的访问压力会瞬间增大。设想一下，如果group1因为压力过大而崩溃，那么更大的压力又会向cache2压过去，最终服务压力就像滚雪球一样越滚越大，最终导致雪崩。
--->为了使对象尽可能均匀地映射到所有的缓存实例中（解决缓存实例分布不均匀的问题），引入虚拟节点的概念。虚拟节点其实为真实节点在hash空间中的复制品，一个真实节点可以对应多个虚拟节点。虚拟节点的hash求值可以在真实节点的求值基础上加入编号等信息 hash(realCacheKey#1) 、 hash(realCacheKey#2)。 图片似乎有问题，虚拟节点并不是hash以后得到zhen'shi'jie'dian
通过虚拟节点的原理我们来解决hash倾斜性的问题：
我们对虚拟节点进行hash时，虚拟节点的hash倾斜性怎么解决？
这就要由hash算法来保证了，均匀分布是概率上的均匀，当虚拟节点足够时，就能保证大概均匀了。
缓存命中率及单一热点问题
一致性xsdhb解决的是某节点宕机后缓存失效的问题，只会导致相邻节点负载增加。但是因为宕机后需要重新从数据库读取，会导致此时缓存命中率下降及db压力增加。
也无法避免单一热点问题。某一数据被海量请求，不论怎么xsdhb，xsdhb环多大，数据只存在一个节点，早晚有被打垮的时候。
此时的解决策略是每个节点主备或主主集群。
hash漂移
某个节点失效了，缓存都漂到下个节点了；然后一会它又恢复了，这时候它就有脏数据了。
解决办法一是每个节点引入集群。
不用集群想彻底解决这个问题，可能需要引入第三方健康检查组件，如Consul，发现节点不稳定立即删除下线。
一致性hash算法最大程度上抑制了键的重新分布（服务器缓存的重新分布），而且我们还可以采用虚拟节点的思想，比如我们每个实际节点都配置100-500个虚拟节点，这样就能抑制分布不均匀。
命中率公式：n是服务器台数，m是增加的服务器，因此随着分布式集群不断扩大，命中率会越来越高。