MOVED错误需立即更新本地槽映射表，实现永久路由；ASK错误仅本次临时跳转，须先发ASKING命令且不更新映射；重试与拓扑刷新应分离，连续两次MOVED异常才触发CLUSTER SLOTS拉取。
处理 Redis 集群中的 MOVED 和 ASK 错误，核心在于区分“永久迁移”和“临时访问”，并据此决定是否更新本地槽映射、是否需要前置命令、以及重试策略是否触发拓扑刷新。
MOVED 错误：必须更新槽映射表
当节点返回 MOVED 5000 127.0.0.1:7002，说明槽 5000 已永久归属新节点。客户端应立即把槽 5000 → 127.0.0.1:7002 的映射写入本地缓存（如哈希表），后续所有对该槽内 key 的请求都直接发往该节点。
- 不要仅重试一次就结束——这次重定向是拓扑变更的明确信号，必须同步更新路由表
- 更新后，同一槽的后续请求不再经过重定向，避免额外网络跳转
- 若使用 redis-py 或 go-redis 等智能客户端，此过程自动完成；若手写客户端，需解析 MOVED 后的 IP:端口并调用类似
refresh_slot_map()的逻辑
ASK 错误：只对当前请求生效，不改映射
收到 ASK 5000 127.0.0.1:7003 表示槽 5000 正在迁移中，key 可能已落在目标节点，但槽责任尚未移交。此时不能更新本地映射，而要在目标节点执行前先发 ASKING 命令。
- 向目标节点（127.0.0.1:7003）先发送
ASKING，再发原命令（如GET mykey） -
ASKING是一次性标识，仅本次请求有效，目标节点凭此允许执行本不属于它的槽的命令 - 本地槽映射仍维持为“槽 5000 属于旧节点”，直到下次收到 MOVED 才更新
重试与拓扑刷新要分开控制
频繁重定向本身不等于集群异常，盲目刷新 CLUSTER SLOTS 可能引发嵌套跳转甚至循环。正确做法是分层响应：
- 首次收到 MOVED：按地址重试一次，同时更新槽映射
- 连续两次 MOVED 指向不同节点（或重试失败）：才触发异步
CLUSTER SLOTS请求，重新拉取全量槽分布 - ASK 错误不触发刷新——它本就是迁移过程中的预期行为，无需干预拓扑视图
客户端模式选择影响处理复杂度
不同客户端抽象层级决定了你是否需要手动处理这些错误：
- Dummy 客户端（如基础 redis-cli 非 -c 模式）：每次遇到 MOVED/ASK 都需人工解析、跳转、重发，效率低且易出错
- Smart 客户端（如 redis-py Cluster、go-redis、Lettuce）：内置槽映射缓存 + 自动重试 + ASKING 注入，只需配置好重试次数和超时，异常由库内部闭环处理
- 生产环境强烈建议使用 Smart 客户端，并确认其版本支持
MOVED/ASK的幂等重试与拓扑自愈逻辑（如 redis-py ≥ 4.6.0）
