https://segmentfault.com/a/11...节点减少、缩小会导致已有数据映射谬误。（三个节点时，5会映射到第二个节点上，缩减为2个节点时，5会映射到第一个节点上，此时去第一个节点其实找不到5）如果分布式缓存大量生效就会产生缓存雪崩。指标：尽可能小的扭转已有数据的映射关系，从而缩小数据挪动的开销。解决分布式哈希表动静伸缩的问题。 哈希算法应满足平衡性:各节点均衡散布，在算法层面做负载平衡枯燥性：新增或删除节点时不影响零碎裕兴分散性：节点只须要保留一部分数据原理对象向2^32-1个桶里hash，放到哈希环上。把服务器也放到哈希环上。顺时针找离对象最近的机器。新增、删除机器时，只有机器左右的对象被影响。为了让重调配更平衡，减少虚构节点，对象先找到本人属于的虚构节点，再找到虚构节点属于的实在节点。一台实在节点对应大量虚构节点，扩散在环的各处，当减少或删除一台实在节点时，很多台其余节点都会受到轻微的影响。
一致性Hash 算法1，介绍一致性hash算法（Consistent Hashing）及其在分布式缓存中的利用，以及对一致性hash算法原理的介绍。2，简略的代码实现3，发现有什么问题不便请指出下。。谢谢。。一，背景咱们通过一个问题思考引入。。 假如咱们有个网站，随着用户量的一直增长，日活量的一直晋升，导致 mysql 的数据读写压力飞速增长，对咱们的服务造成极大的压力。。 为了解决下面的窘境咱们引入了 redis 作为缓存机制，然而你会发现其实随着业务扩张，单台 redis 很快就无奈撑持起你零碎服务，那么为了解决这个问题，咱们会开始引入多台 redis 形成服务集群为网站提供缓存服务； 因为咱们不可能所有的 redis 服务都缓存所有数据，因为这样意义不大，咱们现实的是 每个 redis 服务提供一部分用户的缓存数据，而后依据不同的客户的申请读取不同 redis 的缓存数据； 在这个时候：很多人会想起 hash取模 法； 如上图：依据 Customer_id 取模失去值，依据值流入指定的redis服务中。如果 customer_id 是自增的，咱们每个 redis 服务外面的值的数量都是相对均匀的； 然而短期问题是解决了。。然而你有没有想过，当3个redis 服务无奈失常撑持，须要退出 第 4 个 redis 服务 或者资源过剩了，你心愿回收一个 redis 应用两个 redis 撑持服务了。。然而这个时候你会发现。。 取模的值一旦扭转。。之前缓存的数据就会产生错乱。。这样会有大量的申请穿过你的 redis 缓存服务，间接达到你的 mysql。。而且 redis 缓存服务也缓存着大量无用数据，结果有点可怕。。 为了解决上述问题。。。咱们引入 一致性Hash算法 二，算法简述简略来说咱们把所有数据做一致性hash计算后的所有后果看作一个 hash 闭环，而闭环的大小为0~2^32，也就说所有的数据都会坐落在这个 hash 闭环；如下图： 0 和 2^32 在 hash 闭环中重合，这里为什么要这样做 大家能够思考下。。 下一步咱们把 redis 服务 的IP 也应用 雷同的 hash("redis服务IP") 办法进行求出 hash 值，这样咱们 redis服务 也会坐落在咱们的 hash闭环 中，他的作用 能够看做个桶，承接顺指针流入的数据；如下图： ...