连接池配置不当会放大缓存雪崩影响：max-active过小导致线程排队等待、超时重试，加剧DB压力；应按QPS×耗时×3–5倍设max-active，配齐max-idle、min-idle、max-wait等参数，并确保缓存策略（随机TTL、主动刷新、sync=true）与连接池协同防雪崩。
缓存雪崩和连接池配置不是一回事，但高并发下连接池没配好，会放大雪崩影响——比如大量请求卡在连接获取阶段，等终于拿到连接时，缓存已集体过期，全量打到 DB。
为什么 max-active 设太小会让雪崩更严重
当缓存集中失效，大量线程同时尝试重建缓存，每个线程都要从连接池取 RedisConnection。如果 max-active 过小（如默认的 8），线程会在 pool.getMaxWaitMillis() 内排队等待；超时后抛 CannotGetJedisConnectionException 或类似错误，导致重试逻辑反复触发，进一步加剧 DB 压力。
- 现象：日志里高频出现
Timeout waiting for idle object或Unable to connect to Redis - Lettuce 默认
max-active=8，Spring Boot 3.x 起已弃用 Jedis，Lettuce 是默认客户端 - 压测中吞吐量卡在某个值不再上升，监控显示连接池活跃数长期满、等待队列持续增长
- 不要盲目设成 1000+：单个 Redis 实例能稳定支撑的并发连接数通常在 1k–3k 之间，取决于硬件和网络，超过反而引发内核端口耗尽或 TIME_WAIT 暴增
lettuce.pool 配置项怎么填才不翻车
Spring Boot 的 spring.redis.lettuce.pool 下有 5 个关键参数，其中 3 个必须调，2 个建议调：
-
max-active：按压测结果设，一般为预估峰值 QPS × 平均命令耗时（秒）。例如 QPS=500、平均耗时 20ms → 理论需 10 个连接；留 3–5 倍余量，设为 30–50 更稳妥 -
max-idle：建议等于max-active，避免缩容抖动；设太小（如 0）会导致空闲连接被立即销毁，下次突发流量又要重建连接 -
min-idle：设为max-active的 20%～30%，保证常驻连接，减少冷启动延迟 -
max-wait：设为 1000–3000ms，太短（如 100ms）会让线程快速失败并重试，加重 DB 压力；太长（>5s）拖慢接口响应 -
time-between-eviction-runs：设为 30000（30 秒），配合test-while-idle=true，定期探测空闲连接有效性，避免 DNS 变更或中间件断连后连接池残留假死连接
连接池之外，真正防雪崩的三个动作
连接池只是“通道”，防雪崩得靠缓存策略本身：
- 给批量写入的缓存加随机 TTL 偏移：比如基础过期时间 30 分钟，再 +
Random.nextInt(600)秒（±10 分钟），避免整点失效 - 对核心 key 启用永不过期 + 主动刷新：用
setIfAbsent占位，后台线程定期 reload，而不是依赖被动过期 - 在
@Cacheable上加sync = true（仅限 Spring Cache 抽象层），让同一 key 的并发请求阻塞等待首个加载完成，避免 N 个线程同时穿透 DB
最容易被忽略的是：连接池参数生效的前提是应用真正在用它。检查是否误配了 spring.redis.lettuce.pool.max-active=200，但代码里又手动 new 了 Jedis 实例直连——这种混合用法会让配置完全失效，且极难排查。
