防止缓存雪崩的关键是从设计源头避免大量请求同时涌向后端，核心是打散过期时间、分层设置ttl、构建多级缓存与兜底机制、控制重建节奏、服务端主动防御。
防止缓存雪崩的关键，不是等失效发生后再“挡”，而是从缓存设计源头就避免大量请求在同一时刻涌向后端。核心思路是：打散、兜底、限流、降级。
让过期时间不再整齐划一
统一设置固定TTL（比如全部设为3600秒）是最常见的雪崩诱因。哪怕只是批量导入数据时没加随机偏移，也可能在整点时刻引发数据库洪峰。
- 给基础过期时间叠加随机值，例如：3600秒 ± 300秒，用代码确保每个key的过期时间都略有差异
- 对不同业务等级的数据分层设置TTL：高频变动的配置类缓存设短周期（如5分钟），商品详情设中长周期（如1–2小时），用户基础信息可设更长或配合主动刷新
- 避免使用Redis的EXPIREAT按绝对时间批量过期；改用相对时间+随机扰动的EXPIRE
构建多级缓存与兜底机制
单靠Redis一层扛不住雪崩冲击，必须有缓冲层和兜底策略。
- 本地缓存（如Caffeine）作为第一道防线：即使Redis挂了，热点数据仍能短暂命中，缓解瞬时压力
- 引入二级缓存（如Redis Cluster + Redis Sentinel 或多AZ部署），降低单点故障影响面
- 对关键接口预设“熔断开关”：当DB响应超时率超过阈值（如30%），自动降级为返回缓存旧数据或静态兜底页
控制重建节奏，拒绝并发穿透
缓存失效后的重建过程本身可能成为新瓶颈——多个线程同时查库、写缓存，不仅浪费资源，还加剧DB压力。
- 对热点key启用互斥锁（如Redis SETNX），只允许一个线程加载数据，其余等待或重试
- 采用“逻辑过期”方案：缓存value中嵌入时间戳，物理不过期；读取时判断是否逻辑过期，过期则异步刷新，当前请求仍返回旧值
- 对非实时强依赖的数据，允许一定时间窗口内返回陈旧缓存（stale-while-revalidate）
服务端主动防御不依赖缓存状态
把防御能力下沉到网关或应用层，不把所有希望寄托在缓存是否“在线”。
- 在API网关层配置QPS限流（如基于用户ID或接口维度），防止单点流量爆炸传导到底层
- 对高风险查询（如带模糊搜索、分页深度过大）做参数校验与拦截，提前拒绝非法或低效请求
- 数据库侧开启连接池自动扩容、慢SQL告警、只读副本分流，提升抗压冗余度
