缓存雪崩主因是大量key集中失效或Redis宕机导致请求直击数据库，而非写压力本身；应设随机过期时间（基础TTL+小范围偏移）、Redis故障时用本地缓存+限流+熔断兜底，禁用永不过期，需全链路协同防控。
缓存雪崩不是“写压力”直接导致的，而是大量缓存 key 在同一时间点集中失效，或 Redis 实例宕机后，所有读请求瞬间穿透到数据库——所以高并发写本身不触发雪崩，但写操作若批量刷新缓存且未控制过期时间，会间接加剧雪崩风险。关键在「失效节奏」和「故障兜底」。
怎么给缓存 key 设置随机过期时间
硬编码固定 TTL 是最常见踩坑点。比如统一设为 3600 秒，凌晨 2 点部署后所有热点缓存都在 3 小时后集体过期。
- 基础 TTL 上叠加随机偏移：例如基础 1 小时，再加
0~300秒（5 分钟）随机值，用Random.nextInt(300)生成 - 避免使用系统当前时间做种子（如
new Random(System.currentTimeMillis())），多线程下易重复；改用单例ThreadLocalRandom.current() - Spring Data Redis 中设置方式示例：
redisTemplate.opsForValue().set(key, value, baseTtl + offset, TimeUnit.SECONDS) - 注意：不能对所有 key 都加过大随机范围（如 ±30 分钟），否则部分缓存长期不更新，业务上可能不可接受
Redis 宕机时怎么不让数据库被冲垮
当 Redis 整体不可用，cache miss 变成常态，此时比“怎么缓存”更重要的是“怎么限流+降级”。
- 本地缓存兜底：用
Caffeine或Guava Cache缓存最近读过的 key，哪怕只存 1000 个、过期 10 秒，也能拦下大部分重复请求 - 请求级限流：在接入层（如 Spring Cloud Gateway）或服务入口用
RateLimiter控制每秒最大查询数，超限直接返回503或默认值 - 熔断开关：监控 Redis 连通性，一旦连续失败 N 次，自动打开熔断器，后续请求跳过缓存直走本地缓存或默认逻辑
- 不要依赖“重试机制”来扛故障——重试只会放大雪崩
为什么不能只靠“热点数据永不过期”
把 key 设为永不过期（expire = -1）看似一劳永逸，但实际隐藏三个硬伤：
- Redis 内存不会自动释放：如果业务有数据淘汰策略（如 LRU），永不过期 key 会挤占空间，导致其他 key 被误删
- 数据陈旧难察觉：没人主动更新时，value 可能数天没变，而业务要求最多容忍 5 分钟延迟
- 无法应对 Redis 主从切换或集群重平衡：节点重启后，永不过期 key 全丢失，照样触发集中回源
- 更稳妥做法是：value 里嵌入逻辑过期时间戳，读取时判断是否过期，过期则异步刷新，当前请求仍返回旧值
真正容易被忽略的点是：缓存雪崩从来不是单一技术问题，而是架构链路上多个环节松动后的连锁反应。比如预热脚本没跑、布隆过滤器没加载、本地缓存没配最大容量、Redis 监控告警阈值设得过高——任何一个缺口都可能让“随机过期”这种小优化彻底失效。
