Redis Cluster集群
Redis Cluster 通过 16384 个哈希槽将数据分布到多个主节点，每个主节点可配置从节点做高可用。它解决容量和吞吐扩展问题，但也带来多 key 操作、迁移和客户端路由复杂度。
# 1. 学习定位
| 维度 | 内容 |
|---|---|
| 难度层级 | 分布式架构 |
| 核心目标 | 先会用，再理解机制，最后能做工程取舍和故障分析 |
| 学习方法 | 带着业务场景看命令、SQL、数据结构、日志和运行时指标 |
# 2. 核心地图
Redis Cluster集群
├─ hash slot
├─ MOVED
├─ ASK
├─ 主从分片
├─ 故障转移
├─ reshard
├─ hash tag
└─ 多 key 限制
# 3. 小章节深度讲解
下面把核心地图中的每个点拆开讲。每个小节都同时面向开发和运维：开发侧关注怎么设计、怎么写代码、怎么避免错误；运维侧关注怎么监控、怎么定位、怎么恢复。
# 3.1. hash slot
# 是什么
hash slot 是 Redis Cluster 的数据分布单位。Redis Cluster 固定使用 16384 个槽，key 经过 CRC16 计算后映射到某个槽，槽再归属于具体主节点。
# 开发人员怎么用
开发人员要知道同一个业务聚合如果需要多 key 操作，必须通过 hash tag 控制 key 落在同一槽。例如 order:{123}:detail 和 order:{123}:items 会使用 {123} 计算槽。
# 运维人员怎么看
运维人员要观察槽分布是否均衡、某些槽是否承载热点 key、迁移时槽状态是否正常。扩容不是移动 key 的概念，而是迁移槽及槽内数据。
# 常见风险
常见风险是总节点看起来均衡，但单个槽里有热点 key，导致一个分片被打爆。Cluster 解决容量，不自动解决单 key 热点。
# 3.2. MOVED
# 是什么
MOVED 是 Redis Cluster 的永久重定向响应，表示客户端访问的槽不在当前节点，应该去响应中给出的节点访问。
# 开发人员怎么用
开发人员必须使用支持 Cluster 的客户端，让客户端缓存并刷新槽映射。自己手写重试逻辑时，要正确处理 MOVED 并更新路由，而不是无限重试原节点。
# 运维人员怎么看
运维人员在扩容、故障转移或槽迁移后看到 MOVED 增多，通常表示客户端槽缓存正在刷新。若持续大量出现，要检查客户端拓扑刷新机制。
# 常见风险
常见风险是使用普通单机客户端连接 Cluster，遇到 MOVED 后无法处理，业务表现为大量随机失败。
# 3.3. ASK
# 是什么
ASK 是 Redis Cluster 槽迁移期间的临时重定向。它表示目标节点临时接管某个 key 的访问，但槽的最终归属还没有永久切换。
# 开发人员怎么用
开发人员通常依赖 Cluster 客户端自动处理 ASK。手工实现时，需要先向目标节点发送 ASKING，再执行原命令，且不要把槽缓存永久改到目标节点。
# 运维人员怎么看
运维人员在 reshard 期间看到 ASK 是正常现象。关键是观察迁移速率、业务延迟和失败率，避免迁移批量过大造成阻塞。
# 常见风险
常见风险是把 ASK 当 MOVED 处理，错误更新槽缓存，导致迁移期间路由混乱。
# 3.4. 主从分片
# 是什么
主从分片 属于 Redis 高可用或集群拓扑。它决定数据如何复制、故障时如何提升新主、客户端如何找到正确节点。
# 开发人员怎么用
开发人员要选择支持 Sentinel 或 Cluster 的客户端，并处理读旧数据、重定向、拓扑刷新和跨槽限制。
# 运维人员怎么看
运维人员要监控复制延迟、offset 差距、backlog 命中、Sentinel quorum、槽迁移和每个分片的内存/QPS/延迟。
# 常见风险
常见风险是只看集群总容量，忽略单槽热点、单 key 热点和客户端不支持重定向。
# 3.5. 故障转移
# 是什么
故障转移 属于 Redis 高可用或集群拓扑。它决定数据如何复制、故障时如何提升新主、客户端如何找到正确节点。
# 开发人员怎么用
开发人员要选择支持 Sentinel 或 Cluster 的客户端，并处理读旧数据、重定向、拓扑刷新和跨槽限制。
# 运维人员怎么看
运维人员要监控复制延迟、offset 差距、backlog 命中、Sentinel quorum、槽迁移和每个分片的内存/QPS/延迟。
# 常见风险
常见风险是只看集群总容量，忽略单槽热点、单 key 热点和客户端不支持重定向。
# 3.6. reshard
# 是什么
reshard 是 Redis Cluster 的槽迁移过程，通常用于扩容、缩容或重新均衡。迁移时源节点和目标节点会进入 MIGRATING/IMPORTING 等状态。
# 开发人员怎么用
开发人员要保证业务客户端能正确处理 ASK/MOVED，并避免在迁移窗口执行超大多 key 操作或长 Lua 脚本。
# 运维人员怎么看
运维人员要控制迁移批大小和节奏，观察源/目标节点 CPU、内存、网络、延迟和失败 key。迁移应有暂停、回滚和校验流程。
# 常见风险
常见风险是把 reshard 当成无成本后台操作。大 key 迁移会带来明显网络和主线程压力，严重时影响在线请求。
# 3.7. hash tag
# 是什么
hash tag 是 Redis Cluster 控制槽位的机制。key 中花括号内的内容会被用于计算槽，从而让相关 key 落到同一个槽。
# 开发人员怎么用
开发人员可以用 hash tag 支持多 key 原子操作或同用户数据聚合，但不能滥用。所有 key 都使用同一个 tag 会把 Cluster 打回单分片。
# 运维人员怎么看
运维人员要检查 tag 设计是否造成槽倾斜。热点业务 tag 过于集中时，即使节点很多也无法分散流量。
# 常见风险
常见风险是为了避免 CROSSSLOT，把大量 key 强行放到一个 tag 下，短期解决报错，长期制造热点分片。
# 3.8. 多 key 限制
# 是什么
多 key 限制是 Redis Cluster 的重要边界。涉及多个 key 的命令、事务或脚本，通常要求这些 key 位于同一个槽，否则会报 CROSSSLOT。
# 开发人员怎么用
开发人员在设计 key 时要提前判断是否需要 MGET、MSET、Lua、事务或集合运算。如果需要，就要设计 hash tag 或改成单 key 数据模型。
# 运维人员怎么看
运维人员看到 CROSSSLOT 错误，要推动业务修正 key 模型，而不是只让客户端重试。跨槽限制是架构边界，不是瞬时故障。
# 常见风险
常见风险是单机 Redis 上运行良好的 Lua 和多 key 命令，迁移到 Cluster 后集中失败。Cluster 改造必须做命令兼容扫描。
# 3.9. 本篇学习实验
建议准备一个独立 Redis 实例，构造小 key、大 key、热点 key、过期 key 和慢命令，观察 INFO、SLOWLOG、LATENCY、内存变化和客户端超时。每个实验都要记录命令复杂度和返回数据量。
开发侧实验重点是理解数据结构和命令边界，运维侧实验重点是理解延迟、内存和复制如何变化。真正掌握本篇内容，应该能从延迟尖刺反推大 key、慢命令、持久化或网络问题。
# 4. 核心机制
- key 通过 CRC16 映射到 16384 个槽，槽再分配给不同主节点。
- 客户端访问错误节点会收到 MOVED 或 ASK 重定向，智能客户端会缓存槽映射。
- 同一条多 key 命令要求 key 位于同一槽，hash tag 可让相关 key 固定到同一槽。
- 故障转移在分片内部进行，从节点可提升为主节点。
# 5. 工程实践
- Cluster 客户端必须正确支持槽路由和拓扑刷新。
- 多 key 业务提前设计 hash tag，避免上线后发现命令不可用。
- 扩容缩容要控制迁移速率，避免影响在线延迟。
- 监控每个分片的内存、QPS、延迟、槽分布和复制状态。
# 6. 常见坑
- 把单机 Lua 脚本直接搬到 Cluster，跨槽访问失败。
- key 分布不均，某个槽或分片成为热点。
- 客户端槽缓存不刷新，拓扑变化后大量报错。
- 只看总容量，不看单分片大 key 和热点 key。
# 7. 专家视角
- Cluster 的关键不是节点数量，而是槽分布、热点治理和客户端行为。
- 专家会把 key 命名、hash tag 和业务聚合边界一起设计。
- 分布式 Redis 让容量变大，但单 key、单槽和单命令的限制仍然存在。
# 8. Tips 快问快答
Q：Redis Cluster 有多少槽？
A：16384 个哈希槽。
Q：多 key 命令为什么报 CROSSSLOT？
A：因为多个 key 不在同一个槽。
Q：hash tag 是什么？
A：key 中花括号内的部分用于计算槽，可让相关 key 落到同一槽。
# 9. 阶段小结
Redis Cluster集群 的学习重点不是记住零散概念，而是把它放回真实系统：数据如何进入、如何存储、如何被查询、如何在并发下保持正确、如何在故障后恢复。掌握这些连接关系，才能从“会用”走向“能设计、能优化、能排障”。