聊聊一致性Hash算法

Posted 2021-04-12 丁甲辰

先说背景：

在一些高并发、拥有海量数据的系统中，往往会使用到缓存（如redis,memcache等）。但每个系统都可能会出现这样的情况，比如说用户量的新增、搞一个春节等临时活动等。这个时候呢，现有的缓存服务器不能再支持现有的流量并发等，这个时候呢就需要新增缓存服务器。但是新增服务器会带来哪些影响呢？

首先，我们先想一下，假如没有新增缓存服务器之前。分布式缓存会以哪种方式存着缓存数据

首先想个问题，如何存放缓存数据，又如何获取缓存数据

1：利用hash求余，hhash(key)  % cache.size  hash求余

再不增加缓存的方式上，的确可以做到均衡分布到不同的缓存节点上。

比如有两个数据，一个 A    hash值为7，一个B   值为8

那么7 % 3 = 1   A的缓存就会存放到cache1   B 8 % 3 = 2 存放到cache2

2：但是，增加缓存节点后就会出现问题。

以前 A7 %总数4 = 3   B  8*4=0  两个都已经取错位置了，相当于  （n-1）/n  的概率是找不到以前的数据的，这个时候应用发现cache里没有，就会去数据库，这就相当于以前的缓存数据全部失效，可想而知，这得给数据造成多大的压力

3：我们知道，hash值是一个大于0的整数，我们把hash范围想象成一个圆。

A：我们选取cache服务器的一个属性求hash（如cache节点名），然后想象一下放在环形上

B：把key值求hash，然后又对应放在环形上

C：顺时针找离hash(key)最近的一个hash(cache)节点，如值A就直接放在cache1节点，值B放在cache0上

D：新增cache3缓存节点后，影响的只有cache1到cache3直接的缓存（红色线条部分），不会影响其他缓存

4：但是，3中又有一点缺陷，就是新增少数的节点，会随机影响其他节点。不是均衡影响。为了达到一致性，这个时候就

用到了一致性hash。

在3中，把各个节点有分成N个小节点（其中有专家建议150个），这样的话就能较大程度保证各个节点互相交叉，

新增的节点也分为N份，随机平均（大概率）其他cache节点