Lettuce DNS解析失败主因是默认不主动刷新域名解析结果，启动后缓存IP并复用，即使TTL过期或AWS ElastiCache底层IP变更（如扩缩容、故障转移）也不重查，导致持续连接旧地址而报错；需同时配置动态DNS解析器（DnsResolvingProvider）和启用自适应拓扑刷新（enableAllAdaptiveRefreshTriggers）才能解决。
DNS解析失败不是Redis服务问题，而是客户端在初始化连接时无法把域名转成IP——Lettuce默认不主动刷新DNS，一旦初始解析失败或IP变更，就会卡死在Failed to connect to any host resolved for DNS name。
为什么Lettuce连AWS ElastiCache会突然断连
AWS ElastiCache Redis集群的Endpoint域名（如my-cluster.xxxxxx.us-east-1.cache.amazonaws.com）背后是弹性IP池，底层节点扩缩容、故障转移时IP会变。Lettuce启动时只做一次DNS查询，缓存结果并复用，后续不重查——哪怕TTL已过、实际IP已更新，它仍坚持连旧地址，自然报错。
- 错误典型表现：
Unable to resolve <code>my-cluster.xxxxxx.us-east-1.cache.amazonaws.com: UnknownHostException 或更隐蔽的Failed to connect to any host resolved for DNS name - 关键线索：服务没重启、配置没改、网络一直通，但某天起连接批量超时或拒绝
- 验证方式：手动执行
dig my-cluster.xxxxxx.us-east-1.cache.amazonaws.com +short，对比Lettuce日志里它尝试连接的IP是否一致
启用拓扑刷新的两个必要配置项
Lettuce 6.1+ 支持自动DNS刷新，但必须显式开启且配对使用，缺一不可：
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
-
ClientResources.builder().dnsResolver(new DnsResolvingProvider())：替换默认的静态DNS解析器，启用动态解析能力 -
RedisURI.Builder.redis(host, port).withTopologyRefreshOptions(TopologyRefreshOptions.builder().enableAllAdaptiveRefreshTriggers().build())：触发条件全开，包括MOVED/ASK重定向、连接失败、定期轮询（默认30秒） - ⚠️ 注意：
enableAllAdaptiveRefreshTriggers()不包含「DNS变更」本身——它依赖底层DnsResolvingProvider返回新IP后，再由拓扑刷新机制拉取新节点列表；所以二者必须共存
常见踩坑点：Spring Boot自动配置不生效
Spring Boot Data Redis 2.7+ 默认用Lettuce，但spring.redis.lettuce.cluster.refresh.* 配置项只控制拓扑刷新，**不控制DNS解析器替换**。光配spring.redis.lettuce.cluster.refresh.period=10s没用。
- 必须手写
@Bean定义LettuceClientConfigurationBuilderCustomizer，注入自定义ClientResources - 若用
RedisClusterConfiguration，需确保setTopologyRefreshOptions被调用，而非仅靠属性绑定 - 低版本Lettuce（DnsResolvingProvider，强行升级可能引发
ClassNotFoundException，先检查io.lettuce.core.resource.DnsResolvingProvider是否存在
替代方案：跳过DNS，直连IP（仅限测试或固定环境）
生产环境不推荐，但临时排障或CI/CD流水线中可快速绕过DNS环节：
- 用
dig或nslookup查出当前IP，硬编码进RedisURI（如redis://10.1.2.3:6379） - 注意：ElastiCache节点IP可能随时变化，硬编码会导致后续静默失败
- 更稳妥的做法是脚本化获取：
dig +short my-cluster.xxxxxx.us-east-1.cache.amazonaws.com | head -n1，在容器启动时写入配置文件
真正麻烦的从来不是加两行配置，而是意识到Lettuce的DNS行为和Jedis完全不同——它不刷缓存、不重试、不兜底。线上跑着几十个微服务连ElastiCache，只要有一个没开拓扑刷新，就可能在凌晨三点因一次节点迁移集体失联。
