Redis 哈希槽（Hash Slot）与一致性哈希环（Consistent Hashing）核心对比

---

1. 核心原理与设计目标

维度	一致性哈希环	哈希槽（Redis Cluster）
设计理念	通过虚拟节点将数据均匀分布到环状空间，减少节点变动时的数据迁移量。	将数据划分为固定数量的槽位（16384 个），槽位分配给物理节点，通过槽位迁移实现动态扩展。
适用场景	分布式缓存（如 Memcached）、负载均衡等需要高灵活性的场景。	Redis Cluster 等强一致性分布式数据库，强调数据分片与集群管理的便捷性。
数据分布逻辑	Key 通过哈希计算映射到环上的位置，顺时针找到第一个虚拟节点作为目标。	Key 通过 CRC16 算法计算哈希值后对 16384 取模，确定所属槽位，槽位与节点绑定后定位目标节点。

---

2. 数据迁移与扩缩容

操作	一致性哈希环	哈希槽
节点新增	仅影响环上相邻节点间的数据，需迁移少量数据（部分虚拟节点对应的数据）。	需将部分槽位从旧节点迁移到新节点，迁移单位为槽位（整槽数据一次性迁移）。
节点删除	仅丢失被删除节点上的数据，剩余数据自动由后续节点接管（需重新映射虚拟节点）。	删除节点前需将其负责的槽位迁移到其他节点，保证槽位全覆盖。
迁移复杂度	需维护虚拟节点与物理节点的映射关系，数据迁移分散。	槽位与节点绑定，迁移逻辑集中且明确（通过 CLUSTER ADDSLOTS 和 MIGRATE 命令管理）。

---

3. 负载均衡与数据倾斜

机制	一致性哈希环	哈希槽
数据倾斜处理	引入虚拟节点（如每个物理节点对应多个虚拟节点），分散数据到环的不同位置。	槽位数量固定（16384），节点间槽位分配可动态调整，通过槽位均匀分布实现负载均衡。
扩容后均衡性	新增节点仅接管环上相邻区间的数据，整体分布依赖虚拟节点数量。	槽位重新分配后，新节点可均匀分担旧节点的槽位，数据分布由槽位分配策略决定。

---

4. 优缺点对比

方案	优点	缺点
一致性哈希环	- 节点变动时数据迁移量小 - 天然支持动态扩缩容	- 实现复杂（需维护虚拟节点） - 数据倾斜需手动优化（如增加虚拟节点）
哈希槽	- 实现简单（槽位固定） - 扩缩容以槽位为单位，便于集中管理	- 节点变动需迁移整槽数据 - 槽位分配策略影响负载均衡效果

---

5. Redis 选择哈希槽的核心原因

1. 实现简单高效：

   • 哈希槽将数据分片逻辑与节点管理解耦，通过固定槽位数量（16384）简化路由计算。
   • 一致性哈希需维护虚拟节点和环状结构，复杂度更高。

2. 集群管理便捷：

   • 槽位分配和迁移通过 Redis Cluster 内置命令（如 CLUSTER ADDSLOTS、MIGRATE）集中管理。
   • 一致性哈希需外部协调（如 Zookeeper）或客户端实现路由逻辑。

3. 扩展性可控：

   • 槽位迁移粒度可控（整槽迁移），避免一致性哈希中因虚拟节点分散导致的碎片化迁移。

4. 规避哈希环缺陷：

   • 一致性哈希在节点数较少时易出现数据倾斜，哈希槽通过槽位再分配强制均衡。

---

总结

• 一致性哈希环：适合动态性强、节点频繁变动的场景（如缓存层），通过虚拟节点降低数据迁移成本。

  • 分库分表中间件myCat中的分片算法之一便是一致性hash算法；
    • 其它分片算法：范围、取模、枚举、固定分片Hash、字符串hash解析、时间（按天、按月）

• 哈希槽（Redis Cluster）：适合强调数据强一致性与集群管理的场景，通过槽位分片实现高效扩缩容。

实际应用建议：

• 若需构建 Redis 集群，优先选择哈希槽方案（Redis Cluster），天然支持高可用与动态扩展。
• 若需自研分布式缓存系统，可参考一致性哈希环设计，结合虚拟节点优化数据分布。

扩展阅读：

• Redis Cluster Specification
• 一致性哈希算法实战解析