用于KV集群的一致性哈希Consistent Hashing机制

KV集群的请求分发

假定N为后台服务节点数，当前台携带关键字key发起请求时，咱们一般将key进行hash后采用模运算 hash(key)%N 来将请求分发到不一样的节点上, 后台节点的增删会引发几乎全部key的从新映射, 这样会形成大量的数据迁移，若是数据量大的话会致使服务不可用.

一致性哈希机制

我倾向于称之为一致性哈希机制而不是算法, 由于这其实和算法没太大关系. 设计这种机制的目的是当节点增减时尽可能减少从新映射的key的数量, 尽可能将key还映射到原来的节点上. 而对于一致性哈希机制, 若是集群有K个key映射到N个节点, 那么在增删节点时引发的key的迁移不会超过K/N个.

一致性哈希的原理

一致性哈希机制的原理, 是将集群节点分布到一个圆上, 各节点预设一个key, 这些key的hash值集中后可获得一个数组, 将该数组排序后首尾相连造成一个圆, 节点的key分布在圆的不一样弧段上.

对于请求的key, 其hash值会落入该圆的某一弧段, 按顺时针方向碰见的第一个节点即为其对应节点.

减小节点: 若是删除某一节点, 或者是这个节点故障宕机了, 以前映射到这个节点的key, 会顺时针移到下一个节点, 而其余弧段不受影响.

增长节点: 与减小节点相似, 新的节点会加入到某一个弧段中, 这样原来这个弧段对应的一部分key, 则会落入新加入的节点.

减小热点

因为业务数据的不均或者是哈希算法的缘由, 会形成一些热点节点. 能够经过如下方式减轻节点的热点现象

虚拟节点 Replica

虚拟节点是创建在物理节点之上的一种逻辑节点, 目的是为了将物理节点负责的弧段打散并尽可能均匀(或随机)分布在整个圆上. 实现方式为: 对每个物理节点, 为其建立M个虚拟节点后再加入圆环. 由于这些虚拟节点的key获得的hash值是分散的, 因此其在圆环上的分布也是分散的, 在全部的虚拟节点都加入圆环后, 每一个物理节点实际上都在圆上分散地控制了M段圆弧. 

对于请求的key, 其hash值会映射到某一个虚拟节点, 而热点区域的虚拟节点实际上底下对应的是多个物理节点, 这样就将热点分散到了不一样的物理节点上.

哈希槽 Hash Slot

这是Redis集群的作法, 实际上是虚拟节点的一种特殊形式. 针对使用的哈希算法, 在一开始就将哈希值拆分为1024或更多个小区间, 这些小区间就是哈希槽, 这些哈希槽会映射到不一样的节点. 在节点减小前, 须要将这个节点的哈希槽分配给其余节点, 在增长节点时, 须要将其余节点的哈希槽挪一部分过来. 经过调整哈希槽在各个物理节点间的分配能够对热点进行分散.