迁移中间态的临时通行证
槽迁移过程中会出现一个中间态：客户端拿着旧的路由信息访问源节点，而要读的键其实已经搬到目标节点了，这时源节点只能返回一个临时重定向，指向正在导入该槽的目标节点。客户端收到之后，要先向目标节点发送 ASKING，再重新执行原命令，目标节点才会放行这次访问。这个标记只对紧随其后的那一条命令有效，用完即失效。
基本信息
| 用法 | 先发送允许访问的标记，紧接着执行目标命令 |
|---|---|
| 生效范围 | 仅对紧随其后的一条命令有效 |
| 出现场景 | 槽处于迁移中或导入中的中间状态 |
| 客户端处理 | 主流客户端库会自动完成这套流程 |
| 结束标志 | 迁移完成后不再收到临时重定向 |
典型使用场景
- 手工调试迁移过程，验证目标节点确实能访问已搬过去的键
- 排查迁移期间偶发的访问异常，判断是中间态还是配置错误
- 自研客户端实现重定向处理逻辑时理解两种重定向的差别
- 迁移完成后确认不再出现临时重定向，判断是否真正收尾
- 演练中观察迁移对在线请求的实际影响范围
手工演示
手工演示
redis-cli -p 7001 ASKING # 标记本连接允许访问导入中的槽
redis-cli -p 7001 GET user:1001 # 紧接着执行目标命令才有效
redis-cli -p 7000 CLUSTER GETKEYSINSLOT 1234 5 # 对照源节点的键分布
redis-cli -p 7001 CLUSTER NODES | grep -E 'migrating|importing'两种重定向的区别
| 返回类型 | 含义 | 客户端动作 |
|---|---|---|
| 永久重定向 | 键已稳定归属到另一个节点 | 更新本地路由缓存后重发请求 |
| 临时重定向 | 迁移中间态，键正在搬迁 | 先标记再重发一次，不更新路由缓存 |
| 正常返回 | 键就在当前节点 | 直接使用返回结果 |
| 集群不可用报错 | 槽无归属或状态异常 | 按集群故障处理而不是重试 |
标记与后续命令必须在同一条连接上执行才符合语义，在不同连接上发送就失去作用，手工调试时尤其容易踩到。
迁移正常收尾后临时重定向会自动消失；如果它长期持续出现，说明迁移没有正确完成，需要检查迁移流程而不是继续重试。