一致性哈希算法
一、常规哈希算法
常规的哈希算法在进行扩容的时候,都要进行在哈希计算,重新哈希计算之后的结果通常会和原来的位置不一样,这在做负载均衡和缓存集群的时候,这种改变不是我们想要的(局限性)
因为服务器为了方便用户的访问,会在服务器上缓存数据,加速下一次的访问,因此用户每次访问的时候最好能保持同一台服务器。常规的哈希算法显然解决不了这个问题
比如你有 N 个 cache 服务器(后面简称 cache ),那么如何将一个对象 object 映射到 N 个 cache 上呢,你很可能会采用类似下面的通用方法计算 object 的 hash 值,然后均匀的映射到到 N 个 cache ;
hash(object)%N
一切都运行正常,再考虑如下的两种情况;
1 、一个 cache 服务器 m down 掉了(在实际应用中必须要考虑这种情况),这样所有映射到 cache m 的对象都会失效,怎么办,需要把 cache m 从 cache 中移除,这时候 cache 是 N-1 台,映射公式变成了 hash(object)%(N-1) ;
2 、由于访问加重,需要添加 cache ,这时候 cache 是 N+1 台,映射公式变成了 hash(object)%(N+1) ;
1 和 2 意味着什么?这意味着突然之间几乎所有的 cache 都失效了。对于服务器而言,这是一场灾难,洪水般的访问都会直接冲向后台服务器;
再来考虑第三个问题,由于硬件能力越来越强,你可能想让后面添加的节点多做点活,显然上面的 hash 算法也做不到。
![](https://img2020.cnblogs.com/blog/1468919/202008/1468919-20200816150410103-369845704.png)
我们的每一个缓存节点也遵循同样的Hash算法,比如利用缓存节点的IP做Hash,将节点映射到环形空间当中
那么如何让key和节点对应起来呢?很简单,每一个key的顺时针方向最近节点,就是key所归属的存储节点。所以图中key1存储于node1,key2,key3存储于node2,key4存储于node3。
按这种分配缓存节点的规则,我们再来看看一个增删缓存节点的问题,假设2号节点宕机了,只有key2键会受到影响,key2对应的服务节点变为node3,其它key对应的服务节点不变,如下图
增加服务节点的时候,也只有少部分的key 会收到影响,对应的服务节点也就只有少部分需要迁移
如果出现分布不均匀的情况怎么办?比如下图这样,按顺时针规则,所有的key都归属于统一个节点。
为了优化这种节点太少而产生的不均衡情况。一致性哈希算法引入了 虚拟节点 的概念。平衡性
所谓虚拟节点,就是基于原来的物理节点映射出 N 个子节点,最后把所有的子节点映射到环形空间上。
如上图所示,假如node1的ip是192.168.1.109,那么原node1节点在环形空间的位置就是hash(“192.168.1.109”)。
我们基于node1构建两个虚拟节点,node1-1 和 node1-2,虚拟节点在环形空间的位置可以利用(IP+后缀)计算,例如:
hash(“192.168.1.109#1”),hash(“192.168.1.109#2”)
此时,环形空间中不再有物理节点node1,node2,只有虚拟节点node1-1,node1-2,node2-1,node2-2。由于虚拟节点数量较多,缓存key与虚拟节点的映射关系也变得相对均衡了。