Redis雪崩问题真难搞，面试里遇到考验心态都要稳住才行

Redis雪崩问题真难搞，面试里遇到考验心态都要稳住才行，我记得上次面试，那个面试官推了推眼镜，慢悠悠地问：“项目里用过Redis吧？那缓存雪崩怎么处理？”我脑子里当时就“嗡”了一下，心想完了，这问题听着就吓人，我赶紧把背过的词儿往外倒，什么“设置不同的过期时间”、“用互斥锁”、“搞个熔断机制”……说得自己都觉得虚，因为那时候项目经验浅，根本没真正经历过雪崩现场，全是纸上谈兵，面试官听着也没啥表情,我就知道悬了。

后来真进了公司，接手一个老项目，好家伙，让我给撞上真家伙了，那次是促销活动，零点抢券，技术负责人说缓存扛得住，结果刚到零点，系统“啪”一下就瘫了，页面全白，数据库CPU直接飙到100%，报警短信像疯了一样响，我们一群人围着屏幕，汗都下来了，查了半天，原因土得掉渣：当时为了省事，给抢券活动那一大批热门商品的缓存键，设置了完全一样的过期时间，结果时间一到，缓存“哗”一下全失效了，海量的请求瞬间像洪水一样，直接冲垮了数据库，那场景，真像雪山崩塌一样，拦都拦不住，这就是实实在在的雪崩。（来源：亲身项目故障复盘记录）

那次真是血的教训，光知道理论屁用没有，关键得知道为啥会这样，雪崩说白了，就是大量缓存数据在同一刻集体失效，或者Redis本身挂了，所有请求都绕开缓存，直接砸到数据库上，数据库根本扛不住这种瞬间压力，直接被打死,接着整个服务连锁崩溃。

后来我们吭哧吭哧折腾了好久，才把系统救回来，也长了记性,搞了几条实在的土办法：

第一，过期时间千万别偷懒，再也不能给大批量缓存设同一个过期时间了，我们后来就在基础过期时间上，加个随机数，比如原本设1小时，现在改成1小时加上一个几分钟的随机值，让缓存失效的时间点尽量错开，别小看这几分钟，能把请求高峰拉平,数据库压力就小多了。

第二，热点数据干脆让它永不过期，但这不是真的“永远”，而是我们用个后台任务，偷偷在缓存失效前就去更新它，用户看到的永远是有数据的，只不过数据可能不是最新，但对很多场景来说,短暂旧一点比完全不能用强一百倍。

第三，加锁，这招不能滥用，但关键地方很管用，当缓存失效时，不是让所有请求都去查数据库，而是只让第一个请求去查，查完回填缓存，其他请求等着，我们在项目里用了Redis的setnx命令简单实现了这个锁，虽然粗了点,但确实防止了数据库被重复查询打爆。

第四，也是保命的最后一道防线，做降级和熔断，我们接入了公司的熔断组件，当发现数据库响应慢或者错误率飙升时，直接熔断掉一部分不关键的缓存查询，返回个默认值或者空结果，优先保证核心交易和数据库不死，哪怕让部分用户看到“暂无信息”,也比整个网站挂掉强。

经过这么一遭，我才算真正明白了面试官问的那个问题有多重，它考的不是你背答案的能力，而是看你有没有真正在高压下解决问题的经验，心态崩没崩，现在再有人问我雪崩问题，我肯定不慌不忙，从那次半夜抢修说起，这些东西，书上写得再漂亮，都不如自己栽进坑里爬一回记得牢，所以面试里遇到，心态稳住，就把这当成一次吹牛的机会，说说你是怎么和团队一起，把一座要塌的“雪山”给扛住的。