一致性哈希算法#

优势（vs 取模）： 增减节点只影响相邻区间，避免全量 rehash

虚拟节点： 物理节点映射多个虚拟节点到环上，解决数据倾斜

应用： Redis Cluster(哈希槽16384) / Memcached / 负载均衡

一致性哈希是为了解决分布式系统中节点增减时数据大规模迁移的问题。传统取模方式hash%N，节点数N一变所有数据都要重新映射，也就是全量rehash。一致性哈希的做法是把哈希值空间组织成一个环，节点和数据的key都通过哈希函数映射到环上，每个key顺时针找到最近的节点存放。这样增加或删除一个节点只影响环上相邻区间的数据，其他数据不受影响，大幅减少了迁移量。但一致性哈希有个问题是节点少的时候容易数据倾斜，因为节点在环上可能分布不均匀。解决办法是引入虚拟节点，每个物理节点映射多个虚拟节点到环上，比如一个节点映射150个虚拟节点，这样分布就均匀了。实际应用中Memcached客户端使用一致性哈希做分片，而Redis Cluster选择了哈希槽方案（16384个槽），本质思想类似但实现不同，槽方案更便于管理和迁移。

追问方向：

• “虚拟节点数量设多少？”→ 一般每个物理节点对应 100-200 个虚拟节点即可达到较均匀的分布；节点性能不同时可按权重分配不同数量的虚拟节点
• “和普通取模比优势？”→ 普通取模在节点增减时几乎所有 key 都要重新映射，一致性哈希只影响相邻节点间的数据（约 1/N），大幅减少数据迁移量
• “Redis Cluster 为什么不用？”→ Redis Cluster 用固定 16384 个哈希槽（slot），槽到节点的映射表由集群维护，迁移时按槽粒度移动数据，比一致性哈希的虚拟节点方案更可控、运维更简单

易错点：

• ❌ 一致性哈希完全均匀——需虚拟节点
• ❌ 混淆一致性哈希和哈希槽