哨兵模式下连接池超时必须分层配置：spring.data.redis.timeout仅控制命令执行超时（默认2000ms），不涵盖连接建立、哨兵通信及故障转移；lettuce需协同设置spring.redis.timeout（如5000）和spring.redis.lettuce.pool.max-wait（如3000ms）。
哨兵模式下连接池超时参数必须分层配置，不能只靠 spring.data.redis.timeout 一把抓——它只管命令执行超时，不控制连接建立、故障转移发现或哨兵通信阶段的等待。
spring.data.redis.timeout 不等于哨兵连接超时
这个参数默认是 2000 毫秒，仅作用于 Redis 命令（如 GET、SET）发出后等待响应的时间。它对以下场景完全无效：
- 客户端首次连接哨兵、获取主节点地址的过程
- 主节点宕机后，等待哨兵完成故障转移并通知新主地址的延迟
- 连接池从空闲队列取连接时，该连接已失效但尚未被检测出的问题
如果哨兵集群响应慢或网络抖动，spring.data.redis.timeout 设得太短会导致大量 RedisCommandTimeoutException，但根本原因不在命令本身。
Lettuce 连接池的 max-wait 和 timeout 必须配合设
Spring Boot 2.0+ 默认用 Lettuce，其连接池超时由两个关键参数协同控制：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
-
spring.redis.lettuce.pool.max-wait：线程从连接池获取连接的最大阻塞时间。设为-1ms表示无限等待，生产环境不推荐；建议设为3000ms左右，避免线程长期挂起 -
spring.redis.timeout：仍需同步调高（如5000），否则即使拿到连接，后续命令也可能因网络延迟直接超时 - 若用 Jedis，对应的是
spring.redis.jedis.pool.max-wait和spring.redis.timeout，但 Jedis 在哨兵自动重连上弱于 Lettuce
示例（application.yml）：
spring:
redis:
timeout: 5000
lettuce:
pool:
max-wait: 3000ms
max-idle: 8
min-idle: 2
哨兵通信和故障转移延迟要单独压测
哨兵模式真正的“超时黑洞”在客户端与哨兵节点之间的交互，这部分 Spring Boot 没有暴露直接配置项，依赖底层 Lettuce 的 RedisSentinelConfiguration 和连接工厂行为：
- 哨兵节点列表（
spring.redis.sentinel.nodes）必须填全且可连通，少一个就可能延长发现时间 - 主节点名（
spring.redis.sentinel.master）必须与哨兵配置中sentinel monitor定义的完全一致，大小写敏感 - 建议在应用启动后主动调用一次
redisTemplate.getConnectionFactory().getConnection()触发初始化，观察首次连接耗时是否稳定 - 模拟主节点宕机后，用
redis-cli -p 26379 sentinel get-master-addr-by-name mymaster手动验证哨兵响应是否在预期内（通常down-after-milliseconds+ 少量网络开销）
连接池 idle 参数影响故障转移后的恢复速度
哨兵完成切换后，旧连接池里大量指向原主节点的连接会批量失效。此时如果 min-idle 太低（比如 0），新请求进来就得重建连接，放大延迟；如果 max-idle 太高，又可能堆积大量过期连接：
- 设
min-idle: 2可保证始终有少量“热连接”待命 -
max-idle: 8防止空闲连接过多占用资源 - 务必关闭
testOnBorrow（Lettuce 默认不支持，Jedis 需显式关），否则每次取连接都 ping，反而拖慢故障转移后的首请求
真正容易被忽略的是：哨兵模式下，连接池不是“连上就完事”，而是一个持续感知、动态刷新地址的活体——所有超时参数都要按“最差网络路径”来设，而不是单机 Redis 的经验直觉。
