根本原因是客户端收到MOVED后盲目刷新拓扑并无限重试，导致死循环；应通过max_redirects（如redis-py设为3~5）限制重试次数，并区分ASK（不刷新拓扑、不计数）与MOVED，配合拓扑缓存和合理监控验证。
Redis集群客户端遇到MOVED重定向就卡住，怎么破
根本原因不是网络或服务端问题，而是客户端在收到 MOVED 响应后，盲目刷新拓扑并重试，却没设上限——一旦集群节点映射关系临时错乱（比如主从切换中、槽迁移未完成），客户端就会陷入“重试→MOVED→刷新→重试”的死循环。
关键不是禁用拓扑刷新，而是让它“知止”：明确告诉客户端“最多再试N次，不行就报错”。
-
redis-py从 4.0+ 开始支持max_redirects参数，默认值是16；低于该版本默认无限重试 - Java 的
lettuce用ClusterClientOptions.builder().maxRedirects(3)控制；jedis则需手动包装逻辑，原生不支持自动限重试 - Node.js 的
ioredis默认maxRedirections是16，可通过构造选项覆盖：new Redis({ maxRedirections: 3 }) - 重试次数设太小（如
1）会导致正常槽迁移失败（迁移中短暂返回 MOVED 两次是常态），建议3~5为安全起点
为什么拓扑刷新本身会触发新重定向
客户端收到 MOVED slotid ip:port 后，必须先更新本地 slots → node 映射表，才能把请求发到新节点。但这个“刷新”动作常伴随一次额外的 CLUSTER SLOTS 请求——而如果此时目标节点还没完全接管该槽，它可能又返回新的 MOVED，形成嵌套跳转。
这不是 bug，是集群设计使然：Redis 不保证 CLUSTER SLOTS 返回结果与当前路由状态完全实时一致。
- 避免在重定向路径中同步调用
CLUSTER SLOTS；优先用上一次缓存的拓扑做快速重试，仅当连续失败才强制刷新 -
redis-py的ClusterConnectionPool默认启用拓扑缓存，但若设置reinitialize_steps=1（极少用），会每步都刷，极易诱发循环 - 生产环境务必关闭调试日志中的
log_redirections=True（redis-py），否则重试过程全打日志，掩盖真实瓶颈
MOVED 和 ASK 重定向要区别对待
ASK 表示“这个槽正在迁移中，请先去目标节点执行一次 ASKING 再发命令”，它本意就是临时、单次、不更新拓扑的；而 MOVED 是永久性重定向，必须更新拓扑。混淆二者会导致客户端把 ASK 当 MOVED 处理，强行刷新拓扑，反而破坏迁移流程。
- 所有主流客户端库（
redis-py/ioredis/lettuce）都正确区分了ASK和MOVED，但如果你手写了重定向逻辑，必须显式检查响应前缀是否为"ASK "而非"MOVED " -
ASK重试不计入max_redirects计数（redis-py等默认如此），所以即使设了max_redirects=3，遇到迁移仍可正常完成 - 若发现客户端对
ASK也刷新拓扑，基本可判定用了阉割版/自研客户端，得查底层协议解析逻辑
监控和验证重试是否真被限制住了
光设参数不等于生效。很多团队配了 max_redirects=3 却仍看到无限日志，是因为错误发生在连接池层或超时兜底逻辑里，绕过了重定向控制。
- 在客户端加一行日志：捕获
RedisClusterException（redis-py）或RedisCommandExecutionException（lettuce），看异常消息是否含"Too many cluster redirections"字样 - 用
tcpdump抓包过滤MOVED响应，统计单位时间内同一条命令触发的MOVED次数，超过设定值就说明限制失效 - 模拟故障：手动
CLUSTER SETSLOT X MIGRATING target-node-id后不执行SETKEY迁移，此时持续发请求，观察客户端是否在第N+1次后抛出明确超限异常，而非静默卡死
拓扑刷新的“最大重试次数”不是个保命开关，它只管住重定向链路这一环；真正的稳定性还得靠拓扑缓存的合理性、ASK/MOVED 的精准识别、以及对集群短暂不一致状态的容忍设计——这些地方一松动，限重试就形同虚设。
