什么是一致性哈希算法？Redis 为什么使用哈希槽而非一致性哈希（详细解析）
这是 Redis Cluster 面试必考题 + 架构设计高频问题 。
本文目标：
1️⃣ 讲清 一致性哈希算法的原理与优缺点
2️⃣ 解释 Redis 为什么不用一致性哈希，而选择哈希槽
3️⃣ 给出 工程与面试都好用的对比结论
目录
- [1. 什么问题催生了一致性哈希](#1. 什么问题催生了一致性哈希)
- [2. 什么是一致性哈希算法](#2. 什么是一致性哈希算法)
- [3. 一致性哈希的优点与缺陷](#3. 一致性哈希的优点与缺陷)
- [4. Redis Cluster 的设计目标](#4. Redis Cluster 的设计目标)
- [5. 什么是哈希槽机制](#5. 什么是哈希槽机制)
- [6. Redis 为什么不用一致性哈希](#6. Redis 为什么不用一致性哈希)
- [7. 哈希槽 vs 一致性哈希对比](#7. 哈希槽 vs 一致性哈希对比)
- [8. 适用场景选择](#8. 适用场景选择)
- [9. 面试标准回答](#9. 面试标准回答)
1. 什么问题催生了一致性哈希
最直观的分片方式：
text
node = hash(key) % N问题：
- 节点数量变化时，几乎 所有 key 都要重新映射
- 缓存命中率瞬间归零
- 数据迁移与系统抖动极大
👉 一致性哈希正是为了解决 节点变更导致大规模迁移 的问题。
2. 什么是一致性哈希算法
2.1 哈希环思想
一致性哈希把哈希空间映射成一个 闭合的环：
- 节点通过
hash(node)映射到环上 - key 通过
hash(key)映射到环上
2.2 key 归属规则
从 key 的位置顺时针查找，遇到的第一个节点即为其存储节点。
2.3 节点变更影响
- 新增节点：只影响相邻一小段 key
- 删除节点：原 key 顺延给下一个节点
3. 一致性哈希的优点与缺陷
3.1 优点
- 节点增减时，迁移数据量小
- 非常适合分布式缓存、CDN 等场景
3.2 缺陷（工程视角）
- 数据倾斜
- 节点在环上分布不均
- 依赖虚拟节点
- 实现复杂、调参困难
- 迁移不可精细控制
- 很难做到按计划、小批量、可回滚迁移
4. Redis Cluster 的设计目标
Redis Cluster 从设计之初就强调：
- 分片 + 高可用
- 数据迁移 可控、可观测
- 运维与客户端逻辑尽量简单
5. 什么是哈希槽机制
5.1 核心定义
Redis Cluster 定义了 16384 个哈希槽：
text
slot = CRC16(key) % 163845.2 槽与节点关系
- 每个 master 节点负责一部分槽
- 槽 → 节点 是 显式、可管理的映射
6. Redis 为什么不用一致性哈希
原因一：数据迁移要可控
- Redis 支持 按槽迁移
- 可在线迁移、暂停、回滚
- 一致性哈希难以做到精细迁移
原因二：避免虚拟节点复杂性
- 哈希槽天然解决负载均衡
- 不需要维护大量虚拟节点
原因三：客户端更简单
- 客户端只需维护 slot → node 映射
- 通过
MOVED/ASK自动修正路由
原因四：运维友好
- 扩容/缩容 = 迁移部分槽
- 槽是固定、清晰的最小单位
7. 哈希槽 vs 一致性哈希对比
| 对比维度 | 一致性哈希 | Redis 哈希槽 |
|---|---|---|
| 数据迁移 | 少但不可控 | 可控（按槽） |
| 负载均衡 | 依赖虚拟节点 | 槽均分 |
| 实现复杂度 | 高 | 中 |
| 运维友好性 | 一般 | 很强 |
| 客户端复杂度 | 高 | 低 |
8. 适用场景选择
一致性哈希适合
- 客户端直连分片
- 分布式缓存 / CDN
- 运维与迁移要求不高
哈希槽适合
- 中心化管理的分布式系统
- 需要在线扩缩容
- 强运维诉求（如 Redis Cluster）
9. 面试标准回答
一致性哈希通过哈希环减少节点变更时的数据迁移，但存在数据倾斜、依赖虚拟节点和迁移不可控的问题。
Redis Cluster 使用哈希槽，把 key 映射到固定数量的槽，再由槽映射到节点，从而实现精细、可控的数据迁移，降低系统和客户端复杂度，因此选择哈希槽而非一致性哈希。
一句话总结
一致性哈希解决"少迁移"，
Redis 哈希槽解决"可控迁移 + 易运维"。