Jedis原生连接池默认不处理MOVED，因其仅支持单机模式，设计上将集群逻辑交由JedisCluster封装实现；直接使用JedisPool连接集群会抛JedisMovedDataException。
为什么Jedis连接池默认不处理MOVED
Jedis原生JedisPool只支持单机模式，它压根不知道MOVED是什么——收到响应后直接抛JedisMovedDataException。这不是bug，是设计使然：Jedis把集群逻辑交给了上层封装，比如JedisCluster类。
常见踩坑点：
- 用
new JedisPool(...)连集群地址，却没走JedisCluster - Spring Boot里配置了
spring.redis.host而非spring.redis.cluster.nodes，导致自动降级为单机客户端 - 手动创建
JedisCluster时传入的nodes列表只写了一个节点（如["127.0.0.1:7000"]），首次CLUSTER SLOTS失败后缓存为空，后续所有请求都fallback到MOVED重试
Lettuce如何开启自适应拓扑刷新
Lettuce默认启用集群模式，但AdaptiveClusterTopologyRefresh（自适应拓扑刷新）和PeriodicClusterTopologyRefresh（定时刷新）是关闭的。这意味着一旦初始拓扑拉取完成，它就“躺平”不动，直到下次遇到MOVED才被动刷新——而这个刷新动作本身可能触发新一轮重定向。
必须显式启用并配置：
- 打开自适应刷新：
ClusterClientOptions.builder().enableAdaptiveRefreshTrigger(AdaptiveRefreshTrigger.MOVED_REDIRECT, AdaptiveRefreshTrigger.PERSISTENT_RECONNECTS) - 设置刷新超时：
.adaptiveRefreshTriggersTimeout(Duration.ofSeconds(30)) - 搭配合理的
maxRedirects（如3），避免迁移中短暂双MOVED引发死循环
Spring Boot用户注意：spring.redis.lettuce.cluster.refresh.period仅控制定时刷新，不替代自适应触发；要两者都开才稳妥。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
ASK和MOVED混发时客户端怎么区分处理
ASK和MOVED都带槽位与目标地址，但语义完全不同：MOVED意味着槽已永久归属新节点，必须更新本地映射；ASK只是迁移中的临时跳转，本次请求转发即可，不许改缓存。
实操要点：
- JedisCluster会自动识别
ASK并执行ASKING命令后再转发，无需额外代码 - Lettuce默认也支持，但若你绕过高层API直用
StatefulRedisClusterConnection，就得自己判断响应前缀并调用connection.setReadFrom(ReadFrom.ASK) - 别在
ASK响应后调用CLUSTER SLOTS——它不更新拓扑，纯属浪费
连接池初始化阶段最容易被忽略的三件事
集群客户端启动慢、首次请求延迟高、甚至卡死，往往不是运行时问题，而是初始化就埋了雷：
- 种子节点列表必须包含至少两个可通信的主节点地址（如
["192.168.1.10:7000", "192.168.1.11:7000"]），单点故障或网络抖动时能 fallback - 确保所有Redis节点配置中
cluster-enabled yes且cluster-require-full-coverage no（尤其测试环境），否则任一节点失联就导致CLUSTER SLOTS返回空 - 禁用中间代理（如Twemproxy、云厂商Redis Proxy）参与集群发现——它们会吞掉
MOVED，让客户端永远无法建立正确拓扑
拓扑缓存不是越“新鲜”越好，而是越“稳”越好。频繁全量刷新CLUSTER SLOTS反而放大抖动，精准局部更新才是关键。
