connectTimeout必须手动设置,YAML无对应字段;它控制TCP握手超时,默认10秒,Docker/K8s环境下需设为15~30秒以防DNS慢或网络抖动导致静默失败。
Spring Boot 的 spring.redis.timeout 不是连接超时,它在 Lettuce 中实际映射为 commandTimeout,只管命令执行阶段。真正控制“TCP 握手失败前等多久”的 connectTimeout,YAML 配置文件里压根没提供字段。
这个值默认是 10 秒,但在 Docker 或 K8s 环境下,DNS 解析慢、网络抖动、哨兵返回内网 IP(比如 10.0.1.5)而客户端在公网时,首次连接就会卡住并直接抛 io.netty.channel.ConnectTimeoutException,根本不会触发重试逻辑。
LettuceClientConfigurationBuilder 或 ClientOptions
spring.redis.timeout: 60000 调得再大也没用——连接都建不起来,命令根本发不出去commandTimeout 是整个命令生命周期上限:从序列化、发包、服务端执行、到反序列化完成的总耗时。Lettuce 默认 60 秒,而 spring.redis.timeout 就是它的 YAML 映射入口,会覆盖默认值。
但如果你手动 new RedisClient 或自定义 ClientResources,还会遇到 read-timeout-in-millis。它属于 Netty Channel 层的单次读阻塞上限,和 commandTimeout 不是同一层:
read-timeout-in-millis 应 ≥ commandTimeout,否则可能在命令中途反复触发 Netty 读超时,引发无意义重试甚至雪崩read-timeout-in-millis=5000 但 commandTimeout=10000,一个耗时 8 秒的 HGETALL 可能被中断两次再重发read-timeout-in-millis,除非绕过自动装配Redis 连接超时后,Lettuce 不会自动重连;RedisTemplate 更不会帮你兜底重试。所谓“重连”,本质是业务层捕获异常后重新调用操作方法,或者用 RetryTemplate 包一层。
redisTemplate.opsForValue().get(...) 前手动 try-catch + sleep + retry,太糙RetryTemplate:配 SimpleRetryPolicy(比如最多 3 次)+ FixedBackOffPolicy(间隔 1 秒),并在 @Component 里封装成可注入的服务ClusterTopologyRefreshOptions.builder().enableAllAdaptiveRefreshTriggers().build()
哨兵模式下,Lettuce 会先连一个哨兵获取主节点地址,但如果连第一个哨兵就超时(比如它返回了不可达的内网 IP),Lettuce 不会自动尝试列表里的下一个哨兵——它直接抛异常,重试逻辑也不生效。
这意味着:仅靠 RetryTemplate 重试命令没用,因为失败发生在初始化连接阶段,不是命令执行阶段。
redisConnectionFactory.getConnection().close() 触发连接建立,并捕获 ConnectTimeoutException
spring.redis.sentinel.nodes),并确保它们网络可达、IP 可路由spring.redis.timeout 后发现还是连不上,就是卡在这一步。