「数据量涨十倍，扩容要迁移多少数据？」——这个问题的答案，就是一致性哈希存在的理由。它是分布式存储（Dynamo、Cassandra、Redis Cluster 的设计前身）的基石算法，也是面试中检验分布式思维深度的经典题。这篇从朴素哈希的问题出发，讲清环、虚拟节点、热点治理三层设计，以及它与 CAP 的关系。
一、朴素哈希的死穴：节点数变了，一切重来
缓存集群用 hash(key) % N 分片，N=4 时一切正常。扩到 N=5，几乎所有 key 的映射全部改变——缓存瞬间整体失效，DB 被打穿。数学上：节点数从 N 变到 N+1，key % N 与 key % (N+1) 大概率不同，失效率 ≈ N/(N+1)，接近全量。
二、一致性哈希：把「对节点取模」改成「在环上找位置」
把哈希空间组织成一个环（如 0 → 2^32-1），节点与 key 都映射到环上，key 顺时针找到的第一个节点即归属节点。这样节点增减时，只有相邻区间的 key 需要迁移，失效率从 ~100% 降到 ~1/N（K 个 key 中只迁移 K/N 个）。
三、虚拟节点：解决「环不均匀」与「热点」
物理节点少时，环上的区间划分天然不均，数据倾斜严重。标准解法是每个物理节点映射成 100–200 个虚拟节点散布在环上：区间划分趋近均匀，且新增节点从多个旧节点「各拿一点」，迁移压力分散。虚拟节点同时是异构容量的调节旋钮——性能强的机器多放虚拟节点，自然多承载数据。
# 伪代码：带虚拟节点的一致性哈希
ring = {} # hash(vnode) -> node
for node in nodes:
for i in range(150): # 每节点 150 个虚拟节点
ring[hash(f"{node}#v{i}")] = node
def locate(key):
h = hash(key)
return min(k for k in ring if k >= h, default=min(ring)) # 顺时针第一个值得对照的是 Redis Cluster 的选择：它放弃哈希环，改用 16384 个固定哈希槽，槽是数据归属的最小单位，节点间按槽迁移——本质是把「环」离散化，迁移控制更精细。两种方案思路同源：让数据归属与节点数解耦。
四、一致性哈希与 CAP：分区时的归属权问题
一致性哈希解决「数据放哪」，CAP 讨论的是「分区发生时保什么」。两者在工程上交汇于同一个问题：网络分区时，环上某段的两端节点各自认为自己拥有该区间怎么办？业界答案通常是一致性哈希负责路由 + 强一致协议（Raft 类）负责副本仲裁——即哈希环定分片，每个分片内部用多数派决斈权威，把 CAP 的选择题交给副本层而不是路由层。
一句话总结：一致性哈希的全部价值 = 归属与节点数解耦（环）+ 均匀与弹性（虚拟节点）。面试答到这两层，再能对比哈希槽方案，就是一份完整的回答。
#一致性哈希#分布式系统#数据分片#CAP
