用于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或更多个小区间, 这些小区间就是哈希槽, 这些哈希槽会映射到不同的节点. 在节点减少前, 需要将这个节点的哈希槽分配给其他节点, 在增加节点时, 需要将其他节点的哈希槽挪一部分过来. 通过调整哈希槽在各个物理节点间的分配可以对热点进行分散.