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