connectiontimeoutexception 通常是 lettuce 客户端连接池新建连接超时所致，主因是网络、dns、地址配置或防火墙问题，而非 redis 故障；其默认 connecttimeout 为 30 秒，生产建议设为 3～5 秒。
ConnectionTimeoutException 是连接池没配好，不是 Redis 挂了
看到 ConnectionTimeoutException 别急着查 Redis 服务状态，90% 是 Lettuce 客户端连接池在创建新连接时等太久，超出了 connectTimeout 阈值。这和连接池里有没有空闲连接无关，是「新建连接」这一步卡住了——可能网络延迟高、DNS 解析慢、Redis 实例监听地址不对，或者防火墙拦截了 SYN 包。
-
connectTimeout控制的是 TCP 握手完成耗时上限，默认是 30 秒，生产环境建议压到 3～5 秒 - 如果 Redis 部署在 Docker 或 Kubernetes 里，确认客户端用的是容器内可解析的地址（比如
redis:6379），而不是localhost或127.0.0.1（后者会绕到宿主机 loopback） - DNS 不稳定时，把
host改成 IP 地址，跳过解析环节
Lettuce 连接池资源耗尽的真实表现是 TimeoutException
当所有连接都被占满、且没有空闲连接可用时，Lettuce 不会立刻报错，而是让请求排队等待。一旦超过 poolConfig.getMaxWaitTime()，就抛出 TimeoutException —— 注意不是 ConnectionTimeoutException。这个异常说明连接池“太小”或“请求太慢”，而不是网络不通。
-
maxIdle和minIdle对性能影响不大，但maxTotal必须匹配应用并发量；QPS 为 100、平均 RT 200ms 的服务，理论最小连接数 ≈ 100 × 0.2 = 20，建议设为 32～64 -
maxWaitTime建议设为 1～2 秒；设太长会让线程阻塞堆积，引发雪崩 - 别依赖
blockWhenExhausted = false来“快速失败”，它返回null，容易引发 NPE，不如统一捕获TimeoutException做降级
Spring Boot 2.3+ 默认不用 Commons Pool2，得手动切回 LettucePool
Spring Boot 2.3 起把 LettucePoolingClientConfigurationBuilder 的默认实现从 GenericObjectPool（Apache Commons Pool2）换成了 Lettuce 自带的轻量池，但这个池不支持 maxWaitTime 等关键参数，也无 JMX 暴露，线上排查时会发现监控缺失、超时行为不可控。
- 显式引入
commons-pool2依赖，并在配置中指定：spring.redis.lettuce.pool.type=commons - 否则
spring.redis.lettuce.pool.max-wait这类配置完全无效，应用实际走的是无等待限制的 Lettuce 内置池 - 检查
RedisConnectionFactory类型：如果是LettucePoolingClientConfigurationBuilder且没指定 pool type，大概率踩坑
异步命令 + 连接池超时会导致回调永远不触发
Lettuce 的 asyncCommands() 返回的是 RedisFuture，它底层依赖连接池分配连接。如果获取连接超时，RedisFuture 不会失败，而是卡住——既不 complete 也不 fail，你的 whenComplete 或 thenApply 回调永远不会执行。
- 必须对所有
RedisFuture设置超时：用future.await(3, TimeUnit.SECONDS)或封装成CompletableFuture.orTimeout() - 不要只 catch
ExecutionException，要同时处理TimeoutException和未完成的 future - 日志里搜不到
ConnectionTimeoutException，但大量 future 卡在WAITING状态，基本就是这个原因
