单实例 Redis 的扩展上限很快会撞到内存、CPU 或网络。Cluster 的核心思路,是把 key 映射到 16384 个 slot,再把 slot 分配给不同 master。

Cluster 不是让任意节点代理任意请求,而是让客户端学会路由。请求打错节点时,节点返回 MOVED 或 ASK,客户端再去正确节点。

先把机制边界说清楚

这一篇讨论 Cluster 的路由和迁移,不讨论企业版代理层。开源 Redis Cluster 的很多限制,都来自它坚持客户端路由和异步复制。

整体路径

Cluster 的 slot 路由

上面这张图先把主线铺开:key -> CRC16 -> slot -> master,迁移时出现 MOVED/ASK。Cluster 的关键设计决策都落在「slot 数量为什么是 16384」「重定向怎么区分永久和临时」这些点上,它们决定了路由开销和迁移语义。

底层机制

  • key 通过 CRC16 计算 slot(共 16384 个),slot 决定负责它的 master。
  • 为什么是 16384 而不是 65536——这是 Cluster 几乎必考的设计追问。核心原因是心跳包体积:Cluster 节点之间通过 gossip 协议定期通信,每个节点要把自己负责的 slot 列表发给其他节点,这个列表用 bitmap 表示。16384 个 slot 对应 2KB 的 bitmap,如果用 65536 个 slot 就要 8KB。Redis 作者的判断是官方建议集群规模不超过约 1000 个节点,16384 个 slot 已经为这个规模留足了冗余(每个节点平均负责约 16 个 slot),而更小的 bitmap让 gossip 心跳包更轻、带宽更省。这是一个典型的「按实际规模做工程取舍」而不是「理论最优」的设计。
  • hash Tag 可以让多个 key 落到同一 slot(如 {user100}:profile{user100}:cart 都落在 user100 算出的 slot),从而支持部分多 key 操作。
  • MOVED 表示 slot 归属已经永久变化(迁移完成),客户端应更新路由缓存,后续请求直接走新节点。
  • ASK 常出现在迁移过程中(slot 正在从源搬到目标),表示本次请求临时去目标节点执行,但不要更新路由缓存——因为迁移还没完,下个请求可能还该走源节点。两者的区别是「永久重定向 vs 临时重定向」。
  • Cluster 节点之间用 gossip 协议传播拓扑;跨 slot 的多 key 命令(如 MGET、事务)默认不可用,除非用 hash Tag 强制落到同一 slot。最少部署是 3 主 3 从共 6 节点,保证任一主挂掉都有从可升主。

这些机制放在一起看,就能理解 Cluster 为什么坚持 16384 个 slot 和客户端路由——它在心跳开销、迁移语义和扩展规模之间做了一组相互配合的取舍。

取舍与边界

Cluster 的扩展性来自分片,代价是跨 slot 操作受限、客户端复杂度上升,以及迁移期间路由状态更动态。

典型问题:用机制化例子排查

  • 多 key 命令上线前确认是否跨 slot,必要时设计 hash tag。
  • 不要滥用 hash tag,把大量热点 key 强行绑到同一 slot。
  • 客户端要正确处理 MOVED/ASK,并暴露重定向指标。
  • 扩缩容前先治理大 key 和 slot 倾斜,否则迁移会很痛。

收束:一句判断

Cluster 的第一性原理,是 slot 路由,不是节点会帮你兜底转发。


关于十三Tech

我是十三,All in AI Agent 方向的架构师,专注 AI 工程实践。

我相信 AI 是程序员的最佳搭档,也希望帮助每一位开发者更好地驾驭 AI。

如果你想继续跟完这套「图解 Redis」,欢迎关注公众号 「十三Tech」。后续会继续按数据结构、底层机制、持久化、高可用和实战排查这条线更新。

十三Tech公众号二维码