Redis Cluster MOVED 和 ASK 有什么区别：槽位迁移、客户端重定向与重试边界

Redis Cluster 里看到 -MOVED 和 -ASK，都像是“请换一个节点再试”，但它们的含义并不一样。MOVED 表示客户端的槽位路由已经过期，应更新槽位映射；ASK 只表示当前键正在迁移，下一次请求要临时问目标节点，不能把它当成永久路由。

记住一句话：MOVED 是路由变更通知，ASK 是迁移期间的一次性引导。客户端可以跟随 ASK，但不应因此改写整个槽位表。

先看两种响应到底在提醒什么

假设客户端访问槽位 5798 的键，当前连接的节点认为它不负责这个槽位。若槽位归属已经稳定地落在另一个节点，节点会返回类似下面的响应：

-MOVED 5798 10.0.0.12:6379

这不是普通的临时错误。客户端应把 5798 记到 10.0.0.12:6379，再重发当前命令。若只是槽位迁移尚未完成，源节点可能返回：

-ASK 5798 10.0.0.13:6379

此时目标节点只是暂时接收这个槽位里的某个键。迁移结束前，其他键或后续请求仍可能由源节点处理，所以不能收到一次 ASK 就把整个 5798 槽位永久改指向目标节点。

为什么槽位迁移会产生 ASK

Redis Cluster 迁移槽位时，会经历源节点和目标节点的协作状态。一个槽位还没有完全交接时，某个键可能已经被导入目标节点，也可能仍在源节点。客户端直接访问源节点，源节点需要根据这个键的实际位置给出临时方向。

这里最容易误判的是“ASK 说明源节点已经错了”。更准确的说法是：源节点知道这一次请求应该去目标节点，但集群对外的稳定槽位映射还没有完成切换。

ASKING 为什么不能省略

收到 ASK 后，客户端不能只把原命令发给目标节点。正确的请求顺序是先在同一条目标连接上发送：

ASKING
GET user:1001

ASKING 是一次性的许可信号，告诉目标节点：这条命令来自槽位迁移过程，可以处理本次请求。它不会永久修改节点的槽位归属，也不会替代集群拓扑更新。

如果客户端库把 ASKING 和业务命令放到了不同连接里，目标节点可能仍然按普通槽位检查处理第二条命令，最终出现看似“已经重定向却再次失败”的日志。排查时要把连接 ID、目标地址和两条命令的先后关系一起记下来。

客户端重试应该怎样分层

一个稳妥的重试循环至少要把三类情况分开：

• MOVED：解析槽位和地址，刷新对应路由，再重发当前命令。
• ASK：临时连接目标节点，先发 ASKING，只重发当前命令，不改全局槽位表。
• 超时或连接断开：先判断命令是否可能已经到达服务端。对写命令盲目重发可能造成重复效果，应交给幂等键或业务确认处理。

重试次数也要设上限。例如一个请求最多跟随 3 次重定向，超过后记录槽位、地址、命令类型和最后一个响应，交给上层失败。无限重试会把一次迁移抖动放大成连接风暴。

用三组检查确认问题在哪一层

先从集群视角确认槽位状态：

redis-cli -c -h 10.0.0.11 -p 6379 CLUSTER SLOTS
redis-cli -h 10.0.0.11 -p 6379 CLUSTER NODES

CLUSTER SLOTS 用来查看客户端应该使用的稳定路由，CLUSTER NODES 更适合观察节点角色以及迁移标记。两条命令的结果不一致时，不要只看客户端最后一次重试日志。

再检查客户端是否真的做了正确动作：MOVED 后是否更新了槽位缓存；ASK 后是否在同一连接先发 ASKING；重定向计数是否有上限；目标地址是否被错误地拼成了旧端口。

最后做一次低风险读请求复查。若槽位迁移已经结束，连续读取同一个键仍然收到 ASK，通常要继续看迁移是否卡住、客户端是否复用了过期连接，以及中间代理是否缓存了错误响应。

几个经常混在一起的误区

把 MOVED 和 ASK 都当成“刷新全部路由”

这样做会增加拓扑查询压力，还可能在迁移期间反复覆盖正确的临时判断。MOVED 适合更新对应槽位；ASK 只处理当前请求。

收到 ASK 后直接发送业务命令

缺少 ASKING 时，目标节点不一定接受这次临时访问。客户端库应把两步动作绑定在同一连接上。

所有重定向都无限重试

迁移不是无限持续的理由。重试上限、超时和写命令的幂等策略必须同时存在，尤其是订单、扣库存这类不能简单重复提交的操作。

相关问题

MOVED 出现一次就一定是集群故障吗？

不一定。客户端刚启动、拓扑发生变化或槽位刚完成迁移时都可能出现。重点是客户端能否更新路由，并在后续请求中稳定命中新节点。

ASK 会不会被客户端永久记住？

不应把 ASK 当成永久拓扑。它只服务于当前迁移请求，稳定映射仍应以集群拓扑为准。

排查时最值得保留哪些日志？

保留请求键、计算槽位、原节点、目标节点、响应类型、重试序号、连接标识和最终结果。只记录“重定向失败”通常不足以还原迁移时序。

收尾检查

遇到 Redis Cluster 重定向，先按响应类型分流：MOVED 更新路由，ASK 临时引导并发送 ASKING，网络异常结合命令幂等性决定是否重发。把集群状态、客户端动作和业务结果放在同一条时间线上，才能判断是正常迁移噪声，还是路由缓存、连接复用或迁移状态真的出了问题。