Cluster 哈希槽迁移期间客户端请求会发生什么

Redis Cluster 在迁移哈希槽时不会把整个集群停下来。对正在移动的槽，客户端可能继续从源节点拿到正常响应，也可能收到 ASK、TRYAGAIN，等槽位正式切换后再收到 MOVED。关键不在于“迁移期间一定报错”，而在于请求里的 Key 此刻位于源节点还是目标节点，以及客户端是否正确理解这些响应。

我排查这类抖动时，会先把它当成一次重定向语义检查，而不是直接把所有延迟都归因于 Redis。本文讨论的是基于 CLUSTER SETSLOT 与 MIGRATE 的标准在线重分片语义。官方资料入口：https://redis.io/docs/latest/operate/oss_and_stack/reference/cluster-spec/、https://redis.io/docs/latest/commands/cluster-setslot/。

影响面通常只落在正在迁移的槽位

Redis Cluster 把 Key 空间划分为 16384 个哈希槽。扩容、缩容或重新均衡时，迁移工具逐槽移动 Key。没有参与迁移的槽仍按现有映射服务；正在迁移的槽因为 Key 可能分布在两个节点上，才需要额外的重定向和重试。

典型现场是：大多数请求正常，少数 Key 的延迟突然多出一次网络往返；客户端日志中短时间出现 ASK，迁移收尾时出现 MOVED。如果所有槽都同时抖动，更应该先检查连接池、网络、CPU 或客户端重试风暴，而不是只盯着某一个槽。

# 查看业务 Key 对应的哈希槽，用于把异常请求缩小到具体槽位
redis-cli -c -h redis-node.example -p 6379 CLUSTER KEYSLOT 'order:{42}:detail'

# 查看节点本地视角中的槽位状态，重点关注 myself 行上的迁入/迁出标记
redis-cli -h redis-node.example -p 6379 CLUSTER NODES

迁移开始后，槽位同时处于两种本地状态

假设把槽 8 从源节点 A 移到目标节点 B。目标节点先把槽标记为 IMPORTING，准备接收来自 A 的请求；源节点再把槽标记为 MIGRATING。其他节点和大部分客户端此时仍把槽 8 指向 A，这正是在线迁移能够继续服务的基础。

下面的命令用于解释状态关系，不建议绕过编排工具直接在生产环境手工执行。顺序很重要：目标节点应先进入 IMPORTING，源节点再进入 MIGRATING，否则源节点发出 ASK 时目标可能尚未准备好。

# 先让目标节点 B 准备从源节点 A 导入槽 8
redis-cli -h target.example -p 6379 CLUSTER SETSLOT 8 IMPORTING SOURCE_NODE_ID

# 再让源节点 A 把槽 8 标记为迁往目标节点 B
redis-cli -h source.example -p 6379 CLUSTER SETSLOT 8 MIGRATING TARGET_NODE_ID

同一个槽里的不同请求为什么会拿到不同响应

源节点处于 MIGRATING 后，会按 Key 是否仍存在来决定怎么处理。对单 Key 命令，Key 还在 A 就正常执行；Key 已迁走或原本不存在，就返回 ASK，让客户端临时去 B。这样，新创建的 Key 会落在目标节点，迁移工具只需要继续搬走源节点剩余的旧 Key。

多 Key 命令更容易暴露边界。如果命令涉及的 Key 都在源节点，命令仍可执行；如果都不在源节点，源节点返回 ASK；如果只有一部分存在，Redis 无法在两个节点上原子完成这条命令，会返回 TRYAGAIN。客户端应稍后重试，而不是把请求拆成两个节点各执行一半。

ASK 与 MOVED 的差别决定客户端是否会绕路

ASK 表示“只有下一条请求临时去目标节点”，不能据此永久修改本地槽位表。客户端连接到目标节点后，必须先发送一次 ASKING，再在同一连接上发送被重定向的命令。ASKING 是一次性标记，不能在连接池里换一条连接再发真实命令。

MOVED 的含义相反：当前节点认为槽位已经长期属于另一个节点。客户端可以更新对应槽的目标地址，成熟的 Cluster 客户端通常还会刷新整个槽位拓扑。我的判断标准很简单：看到 ASK 只处理这一笔，看到 MOVED 才改地图。

# 使用 Cluster 模式让 redis-cli 在同一请求处理中自动跟随 ASK 或 MOVED
redis-cli -c -h source.example -p 6379 GET 'order:{42}:detail'

若自行实现协议，必须由支持 Cluster 的客户端在同一连接中发送 ASKING 和被重定向的命令；不能先发 ASKING，再从连接池换一条连接执行真实命令。redis-cli -c 会自动跟随集群重定向，更适合做人工复现。

常见根因不是迁移本身，而是客户端把语义做错了

我更关注四类实现问题。第一，把 ASK 当成 MOVED，提前把槽位缓存改到目标节点，导致下一笔尚未迁走的 Key 又被目标节点重定向回源节点。第二，发送 ASKING 后从连接池取了另一条连接执行命令，一次性标记丢失。第三，对 TRYAGAIN 无限制立即重试，短暂迁移窗口被放大成重试风暴。第四，客户端根本不是 Cluster-aware，把重定向响应直接暴露给业务。

迁移完成时，目标节点和源节点会通过 CLUSTER SETSLOT ... NODE ... 更新槽位归属，配置随后传播到集群。客户端若仍拿着旧映射，访问旧节点会收到 MOVED。这不是数据丢失证据，而是要求客户端刷新路由；只有重定向循环、持续 TRYAGAIN 或迁移结束后仍大量 ASK，才需要继续查状态是否卡住。

修复动作要覆盖重定向、连接和重试三层

优先采用明确支持 Redis Cluster 的客户端，并开启它的槽位拓扑刷新机制。对自研客户端，至少实现以下规则：按 CRC16 与哈希标签计算槽；缓存槽到节点的映射；ASK 不改映射；在同一连接发送 ASKING 与原命令；MOVED 更新映射；TRYAGAIN 使用有上限的退避；重试次数耗尽后把错误返回业务，而不是无限循环。

验证时不要只测单 Key。至少准备同一哈希槽内的已迁移 Key、未迁移 Key、不存在 Key，以及同槽多 Key 命令。Redis 哈希标签可以让相关 Key 固定在同一槽，例如 order:{42}:detail 与 order:{42}:status；若 Key 本来跨槽，多 Key 命令会先遇到 CROSSSLOT，那是另一个问题。

防复发要把“正常重定向”和“客户端缺陷”分开

• 迁移前确认客户端支持 ASK、ASKING、MOVED 和 TRYAGAIN。
• 监控按分钟统计的 ASK、MOVED、TRYAGAIN、重试次数和重定向后延迟。
• 设置最大重试次数与退避，避免迁移窗口被放大成请求风暴。
• 验证连接池不会把 ASKING 与真实命令分配到不同连接。
• 迁移完成后检查客户端槽位缓存是否收敛，并观察 ASK 是否快速下降。
• 多 Key 业务使用一致哈希标签，同时保留 CROSSSLOT 与 TRYAGAIN 的独立告警。

常见问题

ASK 会让客户端永久连接到目标节点吗？

不会。它只要求当前命令临时去目标节点，后续请求仍按旧槽位映射发送，直到收到 MOVED 或刷新拓扑。

迁移期间写入会不会全部失败？

不会。Key 仍在源节点时源节点正常处理；Key 不存在或已经移走时，正确的 Cluster 客户端会跟随 ASK 到目标节点。混合多 Key 命令可能暂时收到 TRYAGAIN。

为什么迁移时 P99 会升高但错误率不变？

ASK 会增加一次到源节点再到目标节点的网络往返，TRYAGAIN 还会引入退避重试，所以尾延迟可能上升；客户端正确处理后，请求仍可成功。

MOVED 很多就说明迁移失败吗？

不一定。槽位归属切换后，持有旧映射的客户端会先收到 MOVED。若数量持续不降，应检查拓扑刷新、DNS/NAT 地址映射和客户端槽位缓存。