前置探活是防雪崩假死最直接廉价的防线，通过pingbeforeactivateconnection在取连接前探测有效性，并需同步配置redis timeout、testwhileidle与timebetweenevictionruns，且连接池参数须设在spring.redis.lettuce.pool下。
前置探活不是“多此一举”，而是让连接池在分配连接前主动验明正身，避免把失效连接交给业务线程——这正是防雪崩假死最直接、最廉价的一道防线。
为什么需要 pingBeforeActivateConnection
Redis 连接可能因网络抖动、中间代理断连、服务端主动踢出（如 timeout 触发）而处于“假活”状态：TCP 连接未关闭，但后续命令必失败。若连接池直接复用这类连接，业务线程会卡在首次 Redis 命令上，超时后重试 → 排队等待新连接 → 更多线程卡住 → 连接池耗尽 → 全量请求打到下游 DB，形成典型雪崩假死。
开启 pingBeforeActivateConnection(true) 后，每次从池中取出连接前，客户端会先发一个 PING 命令探测。成功才交付，失败则丢弃并尝试取下一个空闲连接，从根本上拦截了“带病上岗”的连接。
必须同步对齐的两个关键配置
-
Redis server 的 timeout 参数要与探活节奏匹配：例如设
timeout 300（5 分钟），意味着空闲超 300 秒的连接会被服务端强制关闭。此时客户端的探活必须在此前触发，否则取到的连接大概率已失效。Lettuce 默认不启用探活，需显式开启。 -
连接池的 testWhileIdle 和 timeBetweenEvictionRuns 要配合启用：仅靠激活前探活还不够。空闲连接在池中长期未被使用，同样可能悄然失联。应设置
testWhileIdle=true+timeBetweenEvictionRuns=30000（30 秒），让后台线程定期对空闲连接执行 PING，提前清理“僵尸连接”，减轻激活时的压力。
别踩这个坑：ClientResources 不是连接池参数
有人误把 ClientResources 当成连接池配置入口，在里面调大线程数或 DNS 缓存，结果发现 max-active 完全没变化。这是混淆了层级：ClientResources 管理的是底层 Netty 线程组、DNS 缓存、命令编码器等共享资源，和每个连接池实例的 max-active、min-idle 等完全无关。连接池参数必须落在 spring.redis.lettuce.pool 下，否则所有调优都是无效的。
效果验证看什么指标
上线后重点观察三项日志与监控：
- 日志中
CannotGetRedisConnectionException或Timeout waiting for idle object显著减少； - 连接池活跃数（active）与等待数（waiters）不再长时间满载、持续增长；
- Redis 的
rejected_connections和expired_keys指标波动更平滑，无突发尖峰。
