Appearance
一致性哈希：节点变化时如何减少键迁移
修订于 2026-10-12：原文的“双十一缓存事故”、作者经历和自称基准测试缺少可核查记录，已删除。
它解决什么问题
如果客户端按 hash(key) % N 选择缓存节点，节点数量 N 改变后，许多键会重新映射。对于均匀哈希和简单取模，AWS 的 ElastiCache 文档给出了增加节点时约 (n-1)/n 的迁移比例，其中 n 是扩容后的节点数。由 9 个节点扩到 10 个时，约 90% 的键可能换位置。这个比例描述的是映射变化，不等于缓存命中率一定降到 10%；是否命中还取决于热点分布、预热与回源策略。
一致性哈希把节点和键映射到同一个环形哈希空间。键由沿环某一方向遇到的第一个节点负责。新增节点时，通常只需迁移该节点接管的环段；在分布较均匀的理想情况下，迁移量约为新增后节点数的倒数。它适合节点集合会变化、又希望减少重新映射的客户端分片场景。
虚拟节点的作用与限制
少量物理节点随机分布在环上，可能使各节点负责的区间大小差异很大。可以给每个物理节点分配多个虚拟节点，让环段更细，并按容量调整权重。但“虚拟节点越多越好”并不成立：路由表、节点变更和客户端一致性也有成本。
迁移比例小不代表负载就均衡。少量热键仍可能压垮单个节点；节点的 CPU、内存和网络能力也不一定相同。应分别观察键数量、请求量、流量和延迟。原文把固定种子的 MurmurHash 直接归因为分布不均，这是没有测试依据的推断，已撤下。
上线前检查
- 确定产品的分片机制：并非所有缓存产品都使用客户端一致性哈希。例如 Redis Cluster 按哈希槽路由，不能把本文环模型直接当作它的实现说明。
- 固定映射规则：所有客户端应使用相同的哈希函数、编码、节点标识和虚拟节点配置；变更规则需要迁移方案。
- 验证扩缩容：用真实或脱敏的键分布回放，统计迁移比例、热点分布、回源请求量和延迟。
- 控制回源压力：缓存迁移和失效时，预热、请求合并、限流以及降级策略应一起评估。
- 检查数据一致性：缓存场景可以容忍短暂未命中，但作为持久化分片规则时还需处理副本、迁移状态和故障恢复。