Redis客户端应在捕获MOVED异常时重新拉取集群拓扑，此时向报错节点发送CLUSTER SLOTS获取最新槽映射，仅更新变动槽位，避免全量覆盖和瞬时压力。
Redis客户端什么时候该重新拉取集群拓扑？
只在捕获到 MOVED 异常时才刷新路由表，是正确且必要的行为。其他时机（比如定时轮询、连接建立时全量拉取）不仅浪费带宽和CPU，还会放大集群元数据不一致窗口——因为 MOVED 本身就是集群当前真实分片状态的权威信号。
为什么不能在初始化连接时就拉一次完整拓扑？
很多客户端（如旧版 redis-py-cluster）会在首次连接时调用 CLUSTER SLOTS，但这会引入两个硬伤：
- 新节点刚加入但尚未完成槽迁移时，
CLUSTER SLOTS返回的仍是旧映射，客户端缓存后反而更难收敛 - 客户端若维护多个连接池，每个连接都做一次全量拉取，对集群管理节点（通常是 master）造成瞬时压力，尤其在服务启动洪峰期
真正可靠的起点，是让第一次 GET 或 SET 命中 MOVED 后，再针对性地向报错节点发 CLUSTER SLOTS ——此时返回结果必然反映最新分配状态。
捕获 MOVED 后刷新路由表的具体步骤
关键不是“要不要刷”，而是“刷得准不准”。必须按以下顺序执行，缺一不可：
- 解析
MOVED错误中的目标地址（格式如MOVED 1234 10.0.1.5:7001），提取 IP 和端口 - 用该地址新建一个临时连接（不复用现有连接池），发送
CLUSTER SLOTS - 成功拿到响应后，**仅更新涉及变动槽位的映射**，而非全量覆盖本地路由表（避免覆盖其他未变动槽的健康节点信息）
- 把原请求重试到新节点，同时标记本次重试为“路由修正重试”，防止无限递归（例如连续遇到两次
MOVED）
示例错误：直接拿 MOVED 中的地址去连，却忽略 TLS 配置或密码，导致连接失败，最终路由表卡死在旧状态。
不同客户端库对 MOVED 的处理差异
底层逻辑一致，但封装程度影响出错概率：
-
redis-py（非 cluster 版）：完全不处理MOVED，抛出异常由上层自己 catch，容易漏掉重试逻辑 -
redis-py-cluster2.x：自动重试但默认开启skip_full_coverage_check，可能跳过部分槽校验，导致局部路由失效 -
lettuce（Java）：通过ClusterTopologyRefreshOptions控制刷新策略，默认仅响应MOVED和ASK，最贴近本文建议
真正麻烦的是混合使用场景：比如用 redis-py 写脚本批量导入数据，又没包一层重试+路由更新，只要中间发生一次槽迁移，后续所有请求都会持续打到错误节点，直到手动重启进程。
最易被忽略的一点：某些代理层（如 Twemproxy、Codis）会吞掉 MOVED 并静默转发，导致客户端根本收不到这个信号——这时你再怎么优化客户端逻辑都没用，得先确认流量路径里有没有中间件劫持了集群协议。
