SpringBoot 2.3+需同时配置spring.redis.lettuce.cluster.refresh.adaptive=true和period=60s，并启用validate-after-inactivity清理脏连接，否则节点下线后仍会持续报错。
SpringBoot 2.3+ 直接配 spring.redis.lettuce.cluster.refresh.adaptive 就行
SpringBoot 2.3.0 是分水岭，此前必须写 Java 配置代码，之后只需一行 YAML 就能启用自适应刷新。它会在收到 MOVED、ASK 响应或连接断开时自动拉取新拓扑，不用等超时再重试。
常见错误是只开 adaptive: true 却忽略周期性兜底——节点静默下线（比如运维先删节点再关服务）时，自适应根本没触发机会。
-
spring.redis.lettuce.cluster.refresh.adaptive=true必须设为true，默认是false -
spring.redis.lettuce.cluster.refresh.period=60s建议设为 30–120 秒，太短增加集群压力，太长导致故障感知延迟 - 别漏掉连接池配置：
spring.redis.lettuce.pool.max-idle和max-active要匹配业务峰值，否则刷新后新连接建不起来
为什么开了 adaptive 还会报 Connection to X not allowed
这个异常说明客户端还在用旧拓扑往已下线的 IP:port 发请求，典型原因是自适应刷新被“卡住”了：Lettuce 默认要连续遇到 5 次 MOVED 或连接失败才触发刷新，而生产环境往往第 1–2 次就熔断或降级了，根本凑不够次数。
解决办法不是调低阈值（Lettuce 不暴露该参数），而是确保它能真正“看到”事件：
- 检查
spring.redis.timeout是否过短（如设成1s），导致命令还没走到重定向就被本地超时丢弃，Lettuce 根本收不到MOVED - 确认 Redis 集群返回的
MOVED响应没被中间件（如代理、防火墙）截断或改写 - 如果用的是云厂商 Redis 服务（如阿里云 Tair、腾讯云 CRS），某些版本会把
MOVED包装成自定义错误码，Lettuce 无法识别，得查文档确认是否兼容
SpringBoot 2.2.x 及更早版本必须手写 ClusterTopologyRefreshOptions
配置文件里加再多属性都没用，必须在 @Configuration 类里显式构建刷新选项并注入 RedisConnectionFactory。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
关键点不是“写了就行”，而是触发条件要全开：
- 用
.enableAllAdaptiveRefreshTriggers()，别只开MOVED_REDIRECT—— 节点宕机时更常触发的是DISCONNECTION_DETECTED -
.enablePeriodicRefresh(Duration.ofSeconds(30))的时间单位必须是Duration，传int会静默失效 - 如果项目用了多个
RedisConnectionFactory（比如读写分离），每个都得单独配，漏一个就等于留了个单点故障
拓扑刷新不是万能的，连接池里的脏连接还得靠 validate-after-inactivity
即使拓扑刷对了，连接池里那些指向已下线节点的空闲连接（idle connection）不会自动销毁，下次被取出来还是连不上。
Lettuce 本身不提供连接有效性校验，得靠底层 Netty 的机制：
- 加配置
spring.redis.lettuce.pool.validate-after-inactivity=10000（单位毫秒），让连接空闲超 10 秒后取出前先做一次 ping - 配合
spring.redis.lettuce.pool.test-while-idle=true，否则validate-after-inactivity不生效 - 注意：ping 检查会增加 RT，高并发场景下建议设为 5–10 秒，别设成 100 毫秒这种高频值
最易被忽略的是：拓扑刷新和连接池清理是两套独立机制，只配前者不碰后者，故障恢复期仍可能持续 1–2 分钟。
