一致性哈希为什么需要虚拟节点？

简化版

真实节点在哈希环上的位置随机且数量少，直接映射容易让区间大小差异很大，导致容量和流量倾斜。虚拟节点让每台机器在环上拥有多个离散位置，再把虚拟节点映射回真实节点，从而改善均衡性，并让扩缩容的数据迁移更平滑；它不能代替容量权重、热点治理和副本故障域约束。

一致性哈希把 key 和节点映射到同一个环，key 顺时针找到第一个节点。节点增删时通常只影响相邻区间，而不是像 hash(key) % N 那样让大量 key 重新映射。

若 4 台机器各只有一个环位置，随机落点可能让某台承担 45% 的区间，另一台只有 8%。给每台机器分配 128 个虚拟节点后，每台负责许多分散小区间，统计波动显著降低。

虚拟节点还支持异构容量：高容量机器分配更多 token，低容量机器分配更少。但 token 数不是越多越好，过多会增加路由表、成员变更、迁移任务和元数据广播成本。

面试要补充三个边界：热门 key 即使分布均匀仍会形成访问热点；多副本放置不能把副本落在同一故障域；扩容时必须限速迁移并处理双写、读旧位置和切流时序。

普通取模使用 bucket = hash(key) % N。当节点数从 4 变成 5 时，多数 key 的余数都会变化，缓存场景会造成大面积未命中，存储场景则意味着巨量搬迁。一致性哈希把变化限制在环上相邻区间，解决的是成员变化时的映射稳定性。

取模：hash(key) % 4  -> hash(key) % 5，约 80% 映射可能改变
哈希环：新增节点 X  -> 只接管 X 与前驱之间的区间

哈希函数均匀不代表少量采样点形成的区间均匀。4 个真实节点随机落在环上，四段弧长可能是 8%、17%、30%、45%，最大节点需要承担最小节点五倍以上的数据。节点越少，这种随机方差越明显。

方案	每台环位置数	均衡性	元数据成本
真实节点直映	1	波动大	最低
128 个虚拟节点	128	通常较平滑	中等
数千个虚拟节点	数千	边际收益下降	路由和迁移任务增多

虚拟节点也叫 token。系统先把大量 token 均匀或伪随机放在环上，再把每个 token 归属到某台真实机器。每台机器承担许多彼此分散的小区间，大区间和小区间的随机误差会互相平均。

例如 4 台机器各 128 个 token，总计 512 个小区间。理想占比是 25%，实际可能落在 23%～27%，比单点方案的 8%～45% 更可控。具体误差仍取决于 token 生成、key 分布和样本量，不能把示例区间当成协议保证。

新节点加入后，控制面先发布新环版本并计算它接管的 token。数据面应先复制历史数据，再追增量，达到校验水位后切换权威路由，最后清理旧副本。若先切路由再搬数据，新节点会大量读空；若旧节点过早删除，则故障时无法回退。

分配 token -> 全量复制 -> 追增量/双写 -> 校验 -> 切流 -> 观察 -> 清理旧副本

迁移必须携带 ringVersion 或 epoch。客户端路由过旧时，服务端应重定向或刷新元数据，避免旧客户端持续把写发到已经失去所有权的节点。

异构机器不能机械分配相同 token 数。若 A 有 4 TB、B 有 2 TB，可把初始权重设为 2:1，但还要考虑磁盘 IOPS、网络和压缩开销。权重调整也会引发搬迁，应该渐进改变而不是一次翻倍。

副本选择不能简单取环上连续的三个虚拟节点，因为它们可能属于同一真实节点或同一机架。放置器需要去重真实节点，并按主机、机架、可用区逐层满足故障域约束。虚拟节点负责分区，故障域策略负责可靠性，两者职责不同。

虚拟节点改善的是大量 key 的统计分布。如果某个直播间 key 占 30% 流量，它无论落在哪个 token 都会压垮所属节点。此时要做热点检测、只读副本、请求合并、本地缓存、key 拆分或应用层分片。

监控至少包括每节点容量占比、QPS、P99 延迟、token 数、迁移字节、迁移 ETA 和热点 key。只看 key 数会漏掉大对象和高频对象，只看磁盘又会漏掉 CPU/网络热点。

记忆钩子：虚拟节点是“把一块大责任切成许多小责任再平均分配”，它解决随机区间倾斜，不会自动解决单 key 热点和故障域问题。

先记住两个问题：一致性哈希减少扩缩容时的重映射，虚拟节点减少少量真实节点造成的区间方差。生产落地还要补容量权重、故障域、副本放置和迁移状态机；遇到单 key 热点则进入另一套治理路径。答题时把“均衡、迁移、边界”三层讲清，就不会把虚拟节点神化成万能负载均衡。