某天晚上八点，电商大促刚开抢，用户疯狂刷新商品页——结果首页直接502，购物车打不开，下单按钮灰了。运维一查日志，Redis集群CPU飙到100%，大量请求穿透到数据库，MySQL连接数瞬间占满。这不是服务器坏了，是典型的缓存雪崩。
什么是缓存雪崩？
缓存雪崩不是单个key失效，而是大批量缓存（比如按时间统一设置过期）在同一秒内集中过期。这时所有请求都涌向后端数据库，就像高速路口突然撤掉所有收费站，车全堵死在入口。
最管用的几招，亲测有效
1. 过期时间加随机数
别再写死 setex product:1001 3600 ...。改成加个±300秒的随机偏移：
EXPIRE product:1001 3600 + random(0, 300)2. 热点数据永不过期+后台异步更新
像首页轮播图、爆款商品详情这类访问量极高的数据，干脆不设过期时间。用一个后台任务定时（比如每5分钟）拉取最新数据，主动刷新缓存。哪怕DB慢一点，用户看到的也只是旧数据，而不是报错。
3. 请求互斥锁（Mutex Lock）兜底
当发现缓存没命中，且当前正在重建缓存，就用Redis的 SET key value EX 30 NX 尝试加锁。只让第一个请求去查DB并写缓存，其余请求等100ms后重试读缓存——避免100个并发一起查库。
4. 服务降级与熔断
真遇到雪崩苗头，立刻启用备用方案：比如把商品价格临时从缓存里拿不到时，显示“暂未更新”，而不是查库；或者直接返回预设的静态兜底页（如H5活动页），保主流程可用。
顺手避个坑
别在低峰期批量删缓存。有运营同学习惯凌晨清一次全站缓存，以为“干干净净”，结果早高峰一来，所有热门页同时重建，等于亲手制造雪崩。换成按业务模块分批清理，或者用懒加载方式逐步重建更稳妥。
缓存不是万能胶布，用对方法才能粘得住流量洪峰。