根本原因是jediscluster客户端未及时更新槽位映射，早期版本仅异常驱动单槽刷新；jedis 3.0+需显式配置clusterrefreshperiod（如30000）和refreshtriggeramount（如10）启用后台定时+异常触发的双机制拓扑刷新。
Redis扩容后大面积报 JedisMovedDataException 或 ASK 重定向失败，根本原因不是集群没配好，而是客户端没跟上槽位迁移节奏——它还缓存着旧的 slot → node 映射，且没主动刷新。
为什么 JedisCluster 默认不自动刷新拓扑？
早期 Jedis 版本（如 2.x）的 JedisCluster 初始化时只做一次 CLUSTER SLOTS 拉取，之后全靠异常驱动刷新（比如收到 MOVED 就更新对应 slot 的节点）。但这个机制有硬伤：
- 只在抛出
JedisMovedDataException时才触发单 slot 刷新，其他未访问的 slot 仍指向旧节点 - 若业务大量访问刚迁出的 slot，会持续报错，直到所有相关 slot 都“踩坑”一遍
- 集群正在迁移中（
IMPORTING/MIGRATING状态），MOVED和ASK混发，Jedis 2.x 对ASK处理不完整，容易卡死
换句话说：JedisCluster 不是“懒加载+自适应”，而是“被动踩坑+局部修复”。
开启自适应拓扑刷新的关键配置项
从 Jedis 3.0+ 开始，支持后台定时轮询刷新拓扑，需显式启用。核心是两个参数：
-
clusterRefreshPeriod：单位毫秒，控制多久拉一次CLUSTER SLOTS，建议设为30000（30秒），太短加重集群压力，太长无法及时感知变更 -
refreshTriggerAmount：当累计收到多少次MOVED异常后，强制触发全量刷新（绕过周期限制），设为10较稳妥
初始化示例（Java）：
JedisPoolConfig poolConfig = new JedisPoolConfig();
// ... 其他连接池配置
HashSet<hostandport> nodes = new HashSet();
nodes.add(new HostAndPort("127.0.0.1", 7000));
JedisCluster jedisCluster = new JedisCluster(
nodes,
2000, // timeout
2000, // maxRedirections
poolConfig,
30000, // clusterRefreshPeriod
10 // refreshTriggerAmount
);
</hostandport>
注意：clusterRefreshPeriod 必须 > 0 才生效；若传 0 或负数，等同于关闭自动刷新。
还有哪些地方会堵住路由刷新？
即使开了自动刷新，以下情况仍会导致客户端持续走错路：
- 应用使用了全局单例
JedisCluster实例，但某次迁移后部分线程缓存了旧连接——Jedis 不保证连接对象内嵌的 slot 缓存与后台刷新同步，必须确保所有线程都用同一个JedisCluster实例（而非自己 new Jedis） - Redis 节点配置了
cluster-node-timeout过大（如 > 30000），导致CLUSTER SLOTS返回的节点列表含已下线但未剔除的节点，客户端可能把请求发给“幽灵节点” - 客户端部署在容器或 Serverless 环境，实例冷启时未等待拓扑首次加载完成就处理请求，前几秒必然报错——应加轻量级健康检查（如调用
ping+cluster info）再放行流量
真正麻烦的从来不是“怎么开刷新”，而是“谁在用、什么时候用、用之前有没有准备好”。拓扑刷新不是开关一按就万事大吉的事，它和你的部署模型、线程模型、启动流程强耦合。
