分布式系统可视化教具

一致性哈希 Consistent Hashing

拖动节点、洒下 key、切换算法——亲眼看到为什么一致性哈希只迁移一小段环,而普通取模哈希会在加减节点时把几乎所有 key 打乱。

算法模式

环上定位,加减节点只影响相邻区间。

节点

每个节点的虚拟节点数 100
虚拟节点越多,负载分布越均匀(但计算量增大)。拖到 1 试试负载会有多不均。

Key

本次投放数量 500
key 用 user:随机id 生成,落点由字符串哈希决定。

场景重放

先投放一批 key 稳定分布,再加/删节点,观察下方"迁移统计"面板的高亮变化。
哈希环  一致性哈希 · 0 节点 / 0 key
虚拟节点 稳定 key 刚迁移的 key
节点数
0
0 个虚拟节点
key 总数
0
已投放并定位
最近一次迁移
尚未发生变更
负载均衡度
标准差 / 均值,越低越均匀
迁移比例对比 — 同一次"加节点"操作,两种算法各自要搬多少 key
一致性哈希
取模哈希
添加或删除一个节点,两条对比条会同时更新——取模哈希几乎总是接近 100%。

节点负载分布

是什么

把 key 和节点都扔到同一个环上

把哈希值空间想象成一个首尾相连的圆环(0 ~ 2³²-1)。每个节点通过哈希函数被映射到环上的一个或多个点;每个 key 也被哈希到环上一个点,然后顺时针找到第一个节点,这个 key 就归它管。

为了让负载更均匀,真实系统会给每个物理节点生成多个"虚拟节点"(本页可调),分散插在环的不同位置。

解决什么问题

普通取模哈希,加一台机器等于推倒重来

朴素方案是 hash(key) % N。这在 N 固定时很好用,但只要 N 变化(扩容/缩容/故障),几乎所有 key 的取模结果都会变,等于全量重新分布——缓存系统会瞬间大规模穿透,数据库分片要整体搬迁。

一致性哈希把"是否迁移"变成了局部问题:新节点只切走顺时针方向紧邻它的那一段区间,其余 key 的归属完全不受影响。

为什么这样设计

环 + 虚拟节点,两个设计各解决一个问题

环结构让"重新定位"变成局部操作——只有环上相邻的一小段区间会因为节点增减而改变归属,迁移量与 1/N 成正比,而不是接近 100%。

虚拟节点解决了"环上只有几个点时分布不均"的问题:物理节点数少时,实际管理的弧长可能差异很大;把每个物理节点拆成几十上百个虚拟点均匀撒在环上,大数定律会把负载磨平。这也是 Dynamo、Cassandra、Ketama 等真实系统的做法。