lettuce网络抖动重连失败因默认“被动触发+无兜底”，需同时启用连接池、拓扑刷新与tcp keepalive：缺一不可，否则无法及时感知断连或更新节点地址。
为什么Lettuce在网路抖动时重连会失败
Lettuce默认的重连行为是“被动触发+无兜底”，一旦网络短暂中断（比如SLB心跳超时、云厂商NAT空闲断连、DNS解析延迟），连接可能已断开但客户端未感知，后续命令直接抛RedisConnectionException或RedisCommandTimeoutException。更关键的是：autoReconnect=true只对已建立连接的异常断开生效，对初始化阶段连接失败、DNS解析失败、首次握手超时等场景完全不生效。
必须开启的三个基础配置项
仅设autoReconnect=true远远不够，需组合启用以下三项，缺一不可：
-
spring.redis.lettuce.pool.enabled=true：强制启用连接池，否则Lettuce走单连接模式，重连逻辑不走池化路径 -
spring.redis.lettuce.cluster.refresh.adaptive=true（集群）或spring.redis.lettuce.refresh.period=30s（单机/哨兵）：让客户端主动感知拓扑变化，避免卡在失效节点 -
spring.redis.timeout=5000：显式设为非零值（不能是0），否则Netty底层会立即拒绝连接请求，导致重连根本不会触发
连接池参数要避开的致命陷阱
很多项目把max-active设得过大（如128），反而加剧抖动时的失败率——因为Lettuce在连接池满时会快速拒绝新请求，而不是排队等待重连完成。正确做法是结合QPS压测调整：
-
max-active: 16（中小流量服务足够，避免线程争用） -
min-idle: 2（保底活跃连接，减少首次抖动后重建开销） -
max-wait: 2000ms（超时即报错，不阻塞线程池） - 务必添加
commons-pool2依赖，否则pool配置全部被忽略
TCP层保活必须手动打开
中间设备（防火墙、SLB、K8s Service）通常在60–300秒空闲后静默关闭连接，而Lettuce默认不发TCP keepalive包。必须通过自定义LettuceClientConfiguration注入Socket选项：
SocketOptions.builder() .keepAlive(KeepAliveOptions.builder().enable().idle(Duration.ofSeconds(45)).build()) .connectTimeout(Duration.ofSeconds(3)) .build()
注意idle值必须小于中间设备的空闲断连阈值（建议设为对方值的70%），否则保活无效。
真正容易被忽略的点是：拓扑刷新和TCP保活必须同时启用。只开一个，网络抖动后仍会卡在旧IP或空闲断连；两个都开了，Lettuce才能在毫秒级内发现并重建可用连接。
