Redis Cluster 为什么使用哈希槽？扩容时数据和请求怎么迁移？

知识点详解：键、槽和节点，为什么要分成三层

键先找到槽，槽再找到节点

假设有三台主节点，各自负责一部分槽。键的槽号算法稳定，节点映射可以调整。扩容时，把部分槽及其数据迁给新节点，而不是给所有键重新按四台节点取模。

槽不是一个 Redis 数据结构对象，它是路由与归属的分区单位。稳定状态下，一个槽由对应主节点服务，其副本用于复制和故障切换。

节点更多可以分散不同键，但一个键仍有自己的槽。一个特别热的对象，并不会自动分散成多个节点同时负责写入。

重定向不是两种写法的同一提示

客户端可能缓存着旧槽映射，节点用 MOVED 告诉它去新的归属节点。客户端应适当刷新映射，减少以后重复跳转。

迁移时，有的键还在源节点，有的已经到了目标。ASK 表示这次请求需要按迁移规则去目标节点，先发送 ASKING；不能把它当作整个槽已经永久迁完。

所以普通单节点客户端加上一串地址，不一定就是合格 Cluster 客户端。还要处理拓扑变化、重试和连接池。

同用户，不等于同槽

例如 user:42:profile 与 user:42:quota 按完整键名哈希，未必同槽。有效的 hash tag 如 user:{42}:profile 与 user:{42}:quota 可以按相同标签映射。

这有利于需要同槽执行的多键操作，但代价是这些键集中到一处。如果所有用户都用了同一个 {users} 标签，反而失去分布效果。

还要按命令和版本核实限制。不能把“多键操作受同槽限制”说成所有客户端都不能分组并行读多个节点，也不能把客户端分组读误称跨槽原子事务。

分片以后，容量和故障仍要逐节点看

总内存很大，不代表每个节点都还有空间。槽分布、键大小与热点可能造成不均衡，迁移过程也会消耗网络和内存。

副本故障切换需要满足集群规则，可用性还受覆盖要求与配置影响。默认异步复制仍有丢失已响应写入的窗口。

验收应覆盖重定向、迁槽、多键边界、热点与网络故障。只测稳定拓扑下的 SET 成功，不足以说明集群客户端和运维设计可靠。

本题机制参考：Cluster 规范、Cluster 扩展、集群多键操作。

面试官继续追问

16384 是节点数量吗？

不是，是槽数量。实际节点通常远少于槽，一个节点可管理多个槽。

hash tag 能解决所有跨槽问题吗？

只能把按规则计算的键放同槽，不能创造跨节点原子事务；集中太多数据还会变成热点。

Cluster 和 Sentinel 怎么选？

主要是容量与分片需求不同。Sentinel 管非 Cluster 主从高可用；Cluster 内部有自己的分片和切换机制，不是简单再给 Cluster 每个节点套 Sentinel。

面试速记卡

• 映射：key → 16384 槽 → 主节点。
• 扩容：迁移槽，不是修改节点数取模。
• MOVED：归属更新；ASK：迁移中的临时访问。
• 多键：常规原子操作看同槽，hash tag 管相关键。
• 边界：单键不透明拆分，异步复制仍有风险。