当前位置：首页 > 文章列表 > 数据库 > Redis > Cluster 哈希槽迁移期间客户端请求会发生什么

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

来源：17golang原创 2026-10-08 18:57:08 0浏览收藏

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/。

迁移期间最重要的四种结果

Key 仍在源节点：源节点正常执行命令。
Key 已不在源节点：源节点返回临时的 ASK，客户端只重试这一次请求。
同一命令中的多个 Key 只有部分仍在源节点：返回 TRYAGAIN。
槽位所有权已经切换：旧节点返回 MOVED，客户端更新槽位映射。

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

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，这正是在线迁移能够继续服务的基础。

业务 Key、哈希槽 8、槽位映射、源节点 MIGRATING 与目标节点 IMPORTING 的静态结构关系图 — 图1：槽位迁移的双节点状态说明图。客户端映射仍指向源节点，目标节点只在导入状态下接收经过授权的临时请求。

下面的命令用于解释状态关系，不建议绕过编排工具直接在生产环境手工执行。顺序很重要：目标节点应先进入 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。客户端应稍后重试，而不是把请求拆成两个节点各执行一半。

已存在 Key、不存在 Key、混合多 Key 分别对应正常响应、ASK 加 ASKING、TRYAGAIN，并在槽位切换后对应 MOVED 的静态关系图 — 图2：迁移期间的客户端响应关系说明图。判断依据是 Key 的位置和槽位所有权，不是随机错误。

请求状态	服务端响应	客户端动作
Key 仍在源节点	正常响应	使用响应，不改槽位映射
Key 不在源节点	ASK 目标地址	同一连接先发 ASKING，再重试当前命令
多 Key 只有部分在源节点	TRYAGAIN	短暂退避后重试原命令
槽位所有权已切换	MOVED 新地址	更新或刷新槽位映射，再重发命令

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，那是另一个问题。