必须先发ASKING命令才能执行重定向命令，因为迁移中的槽处于临时不可写状态，ASKING是单次权限豁免开关，仅对当前连接下一条命令生效。
ASK重定向时为什么必须先发 ASKING 才能执行命令
Redis 集群在做槽位迁移（CLUSTER SETSLOT ... MIGRATING / IMPORTING）时，目标节点收到不属于自己的槽请求，会返回 ASK 重定向响应。但客户端如果直接把原命令发给新节点，会被拒绝——因为迁移中的槽处于“临时不可写”状态，新节点默认不接受未授权的写操作。
解决办法就是：在重定向后、发真实命令前，**必须显式发送一次 ASKING 命令**。这个命令不是查询，而是一个“开关”，它让接收节点临时允许本次连接执行一次针对该槽的操作。
-
ASKING只对当前 TCP 连接生效，且只影响下一条命令；发完就失效 - 不发
ASKING就直接发SET key value，新节点会返回MOVED或TRYAGAIN（取决于槽状态），而不是执行 - 读命令（如
GET）在IMPORTING状态下也可能被拒绝，同样需要ASKING
客户端如何正确处理 ASK 响应流程
标准流程不是“收到 ASK → 换节点 → 发命令”，而是四步闭环：
- 原节点返回类似
ASK 12345 127.0.0.1:7002的响应 - 客户端断开当前连接（或复用连接但清空认证/DB上下文），建立到
127.0.0.1:7002的新连接（或切换已有连接的目标地址） - 在新连接上，**先发
ASKING，再发原始命令**（例如SET mykey hello） - 如果命令成功，继续；如果失败（比如槽还没完全导入），可能要回退到原节点重试或等待
CLUSTER NODES确认状态
注意：很多轻量客户端（如某些 Lua 脚本或自研工具）会漏掉第 2 步的连接切换，直接在旧连接上发 ASKING ——这没用，因为 ASKING 只在目标节点上起作用。
ASKING 和 READONLY / READWRITE 的区别在哪
三者都是控制节点行为的“模式切换命令”，但作用域和触发条件完全不同：
-
ASKING是临时、单次、面向迁移中槽的写权限豁免，仅在ASK重定向场景下有效 -
READONLY是连接级只读模式，影响所有后续命令（包括对本地槽的读），常用于连接从节点；不解决ASK场景 -
READWRITE是取消READONLY，恢复读写，跟槽迁移无关
混淆它们会导致：用 READONLY 替代 ASKING，结果命令仍被拒绝；或者在非迁移场景滥用 ASKING，虽无害但多余。
生产环境容易忽略的两个细节
一是超时与重试边界：当 ASK 后发 ASKING 再发命令，若网络延迟高或目标节点正忙，可能触发客户端超时。此时若简单重试原命令（没重新走 ASKING 流程），大概率失败。
二是管道（pipeline）场景：ASKING 只影响紧随其后的**下一条命令**，不能放在 pipeline 开头然后塞一堆命令进去。每个需重定向的命令都得单独配一个 ASKING + 命令对。
这些细节不报错，但会让迁移期间的命令成功率掉得莫名其妙——问题往往出在客户端没严格按协议走，而不是 Redis 本身不稳定。
