缓存雪崩本质是大量key过期时间集中导致请求穿透至数据库，需通过过期时间随机化、逻辑过期、二级缓存错峰、主动预热等手段防控。
缓存雪崩的本质是过期时间集中，不是Redis本身的问题
缓存雪崩不是Redis崩溃或响应变慢，而是大量key在同一时刻过期，导致请求穿透到数据库，瞬间压垮后端。关键不在“Redis扛不住”，而在“业务层没分散过期策略”。只要所有expire写死成相同值（比如统一设3600秒），就埋下雪崩隐患。
常见错误现象：redis-cli --scan --pattern "user:*" | xargs -I{} redis-cli ttl {} 扫出来一堆-1（永不过期）或大量相同ttl值，说明过期时间没做随机化。
- 设置过期时间时，必须叠加随机偏移量：比如基础TTL是3600秒，就用
EXPIRE key 3600 + random.randint(1, 600) - 避免用
SETEX直接写死，优先用SET key value EX 3600+ 应用层加扰动 - 如果用Spring Data Redis，别依赖
@Cacheable(expire = 3600)这种全局配置，改用RedisTemplate手动控制
用逻辑过期替代物理过期，把“过期判断”从Redis移到应用层
物理过期（EXPIRE）由Redis自动清理，但不可控；逻辑过期是把过期时间存为value的一部分，由应用读取后自行判断是否“该更新了”。这样Redis里key永不自然淘汰，避免集中失效。
使用场景：读多写少、允许短暂陈旧数据的热点数据，比如商品详情、用户资料页。
- 存储结构示例：
SET user:123 '{"data":{"name":"Alice"},"expire_at":1717028450}' - 读取时先查
GET user:123，解析JSON，检查expire_at是否已过期 - 若过期，启动异步线程刷新缓存（不阻塞当前请求），同时给旧数据加个短续期（如
EXPIRE user:123 60防并发击穿） - 注意：不能省略对
expire_at字段的校验逻辑，否则和物理过期无异
二级缓存 + 过期错峰，让本地缓存分担Redis压力
单靠Redis无法解决雪崩，得靠本地缓存（如Caffeine）做第一道缓冲。它的TTL要明显短于Redis的TTL，并且各自独立随机化，天然形成错峰。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
参数差异：Caffeine.newBuilder().expireAfterWrite(10, TimeUnit.MINUTES) 和 Redis 的 EXPIRE key 3000（50分钟）+ 随机±300秒，两者生命周期不重叠。
- 本地缓存只存高频、低更新频率的数据，避免频繁回源刷新
- 当本地缓存未命中，才查Redis；Redis也未命中，才查DB并双写（先写Redis，再写本地）
- 不要用
LocalCache + RedisCache两级都设相同过期时间，那等于把雪崩风险复制两份 - 警惕Caffeine的
refreshAfterWrite——它会后台异步刷新，但不保证刷新成功，需配合降级兜底
预热 + 主动刷新，让过期变得“可预测”而不是“被动承受”
上线前或大促前，主动加载一批高频key并设好带扰动的过期时间，比等用户请求触发更可控。这不叫“预防”，是把雪崩从“突发”变成“计划内任务”。
性能影响：预热本身有IO开销，但远小于雪崩时数据库被打满后的连锁故障。
- 用
pipeline批量写入预热数据：redis-cli --pipe ，其中<code>warmup.txt每行是SET key value EX 3600类命令 - 结合定时任务（如Quartz或XXL-JOB），每小时扫描一次即将过期的热门key（用
SCAN+TTL），提前10分钟刷新 - 别在凌晨2点全量刷新——要按业务访问波峰错开，比如电商关注晚8点，内容平台关注午休时段
- 预热脚本必须包含失败重试和日志记录，否则“以为刷了，其实漏了”才是最危险的
真正难的不是加随机数或写个预热脚本，而是把过期策略变成每个新功能的必填项——就像写SQL必须加索引提示一样，成为开发习惯。一旦松懈，雪崩不会等你发版通知。
