单实例 Redis 的扩展上限很快会撞到内存、CPU 或网络。Cluster 的核心思路，是把 key 映射到 16384 个 slot，再把 slot 分配给不同 master。
Cluster 不是让任意节点代理任意请求，而是让客户端学会路由。请求打错节点时，节点返回 MOVED 或 ASK，客户端再去正确节点。
先把机制边界说清楚
这一篇讨论 Cluster 的路由和迁移，不讨论企业版代理层。开源 Redis Cluster 的很多限制，都来自它坚持客户端路由和异步复制。
整体路径
上面这张图先把主线铺开：key -> CRC16 -> slot -> master，迁移时出现 MOVED/ASK。读 Redis 这类系统，最重要的是别只停在命令接口，要继续追问它在内存里是什么形状、在主线程上走多远、失败时会留下什么状态。
底层机制
- key 通过 CRC16 计算 slot，slot 决定负责它的 master。
- hash tag 可以让多个 key 落到同一 slot，从而支持部分多 key 操作。
- MOVED 表示 slot 归属已经变化，客户端应更新路由缓存。
- ASK 常出现在迁移过程中，表示本次请求临时去目标节点执行。
这些机制放在一起看，就能把「这个命令能不能用」改成「这个命令在当前数据规模下还便不便宜」。Redis 的很多坑，不是命令本身错了，而是数据规模和访问方式已经越过了它的舒适区。
取舍与边界
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」。后续会继续按数据结构、底层机制、持久化、高可用和实战排查这条线更新。
