根本原因是客户端未启用集群模式或使用单点库连接集群：redis.redis()不解析moved响应，redis-cli不加-c参数也不会自动跳转；必须改用rediscluster.rediscluster并传入多个种子节点，或redis-cli -c启动。
为什么客户端收到MOVED却没跳转
根本原因是客户端没启用集群模式，或者用了单点连接库去连集群。比如用 redis.Redis() 连集群节点，它压根不解析 MOVED 响应；redis-cli 不加 -c 参数也一样——返回 (error) MOVED 12345 10.0.0.5:6379 就停了，不会自动重试。
实操建议：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- Python 必须用
rediscluster.RedisCluster初始化，且传入全部种子节点（不止一个） -
redis-cli必须带-c启动，连上后执行命令看到Redirected to slot [xxx] located at [xxx]才算生效 - 检查客户端日志里是否出现
ConnectionError或TimeoutError：这些底层失败会中断重定向链，导致你只看到第一次MOVED，实际根本没走到重试逻辑
如何区分MOVED和ASK并正确处理
MOVED 表示槽已永久归属新节点，必须更新本地 slots → node 映射；ASK 表示槽正在迁移中，只对本次请求临时跳转，绝对不能改映射表。混淆这两者是重定向循环的主因。
实操建议：
- 解析响应时严格匹配前缀：
if err.Error()[:4] == "ASK "，别用strings.Contains(err.Error(), "ASK")，否则可能误判ASKING命令失败或日志里的单词 - 遇到
ASK必须先发ASKING命令（无参数），再发原命令；漏掉这步，目标节点会拒绝并返回新的MOVED或ERR - 收到
MOVED后，只在重试成功后才更新拓扑缓存；不要一收到就刷，否则可能把临时错乱当真
重定向次数爆炸或死循环怎么查
默认重试上限太高（如 redis-py 是 16 次）+ 拓扑刷新时机不对，就会让一次临时网络抖动演变成几十次嵌套跳转。典型现象是日志里连续出现 Redirecting to ...，最后超时或报 Max redirections reached。
实操建议：
- 显式设
max_redirections=3（redis-py）、maxRedirections: 3（ioredis）、MaxRedirects = 3（go-redis）——设太小会误杀正常迁移（一次迁移常触发 2 次MOVED），设太大容易死循环 - 禁用同步拓扑刷新：比如
redis-py的reinitialize_steps=1会在每次重定向都发CLUSTER SLOTS，极易引发竞态；应改为失败 2 次后再异步刷新 - 拓扑缓存加 5 分钟过期，但扩缩容后要主动调
refresh_nodes()或类似方法，不能只等超时
服务端状态异常也会伪装成重定向问题
客户端一切配置正确，但依然反复 MOVED 或写入失败，大概率是集群元数据不一致。比如某个主节点标着 master，但实际已失联，或 CLUSTER SLOTS 返回的槽范围有空缺。
实操建议：
- 在任意节点执行
CLUSTER NODES，逐行检查是否有fail?或fail标记；注意fail?节点集群还能写，但已有风险 - 执行
CLUSTER SLOTS，确认输出覆盖全部 16384 个槽，且每段区间连续、无重叠或缺口 - 如果发现某主节点所有从节点都断连或也标
fail，即使它自己还活着，实际已失去容错能力，此时MOVED可能指向一个不可用节点
ASK 和 MOVED 的语义混淆、重试策略失控，或是服务端元数据延迟未收敛。
