lettuce默认不刷新redis cluster拓扑，因其基于netty长连接缓存slot-node映射，需显式配置自适应刷新（spring.redis.lettuce.cluster.refresh.adaptive=true）和定期刷新（spring.redis.lettuce.cluster.refresh.period=60s）双机制，缺一不可。
Spring Boot连接Redis Cluster最常踩的坑不是连不上，而是“连上了却用不对”——拓扑信息过期、MOVED重定向失败、节点变更后请求持续打到下线节点。根本原因在于Lettuce默认不刷新集群视图，必须显式配置。
为什么Lettuce默认不刷新Cluster拓扑？
Lettuce基于Netty长连接设计，建立连接后会缓存整个集群的slot-node映射关系。它不像Jedis那样每次命令都校验节点有效性，而是依赖主动刷新机制。没配刷新策略时，哪怕集群已扩容或故障转移完成，客户端仍按旧拓扑路由请求，直接报错：
java.lang.IllegalArgumentException: Connection to 10.0.1.5:6379 not allowed. This connection point is not known in the cluster viewio.lettuce.core.RedisCommandTimeoutException: Command timed out after 10 second(s)
这不是网络问题，是客户端“活在过去的拓扑里”。
必须配置的两个核心刷新参数
Spring Boot 2.3+ 提供了开箱即用的Lettuce集群刷新配置，缺一不可：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
-
spring.redis.lettuce.cluster.refresh.adaptive=true：开启自适应刷新。遇到MOVED/ASK响应、连接断开、节点不可用时立即触发拓扑更新，秒级生效 -
spring.redis.lettuce.cluster.refresh.period=60s：设置定期刷新间隔。生产环境建议60–120秒；设太短（如10s）会增加哨兵/集群节点查询压力；设太长（如5分钟）会导致故障转移后长时间不可用
注意：adaptive和period是互补关系，不是二选一。只开adaptive无法覆盖节点静默下线场景；只开period又无法应对突发重定向。
连接池与超时配置容易被忽略的细节
集群模式下连接池行为更敏感，错误配置会放大拓扑问题：
-
spring.data.redis.lettuce.pool.max-active建议设为8–20，不能照搬单机配置。集群有多个节点，连接需分散，过小会导致连接争抢 -
spring.data.redis.timeout必须带单位，如5000ms或5s。写成5000会被Spring Boot 2.x+忽略，实际使用默认值（通常2秒），极易触发RedisCommandTimeoutException - 集群环境下
spring.data.redis.database无效——Redis Cluster不支持SELECT命令，该配置会被Lettuce静默丢弃，不要写
验证拓扑刷新是否真正生效
光配参数不等于解决问题。上线前必须模拟节点变更验证：
- 手动执行
redis-cli -c -h node1 -p 6379 CLUSTER FAILOVER触发主从切换 - 观察应用日志是否出现
Refreshing cluster topology字样（Lettuce debug日志级别） - 检查
CLUSTER NODES返回结果中角色变化后，应用是否在1–2秒内停止向原master发请求
最容易被忽略的是：Lettuce的拓扑刷新日志默认是DEBUG级别，不调日志级别就看不到刷新动作，误以为配置没生效。
