获课：97it.top/17509/

从缓存穿透到雪崩：Redis在秒杀场景下的多级缓存防护

在每年的“双11”或热门演唱会门票开售时，我们常常会遇到页面卡顿甚至崩溃的情况。对于背后的技术团队来说，这其实是一场关于“高并发”的极限防守战。而在这场战役中，Redis缓存就像是挡在数据库前的一道核心防线。今天，我们就从教育的视角出发，深入浅出地聊聊Redis在秒杀场景下必须面对的三大挑战：缓存穿透、缓存击穿和缓存雪崩。

为了让大家更直观地理解，我们可以把数据库想象成一位动作缓慢但知识渊博的“老教授”，而Redis缓存则是他身边一位反应极快、能秒回常见问题的“学霸助手”。秒杀开始的那一刻，就像是有成千上万的学生同时冲进办公室提问。

第一个挑战：缓存穿透（问了一个根本不存在的题）
缓存穿透是指有用户故意查询一个数据库里根本不存在的数据（比如一个不存在的商品ID）。当请求到来时，“学霸助手”Redis发现缓存里没有，只能去问“老教授”数据库；数据库查了一圈发现没有，也只好返回空。如果黑客利用成千上万的无效ID发起攻击，数据库就会被这些无意义的查询活活累垮。
如何防护？ 我们可以在“学霸助手”前面再加一道“门卫”（通常使用布隆过滤器），提前把所有合法的商品ID记在脑子里。如果门卫发现你问的问题ID根本不在名单上，直接把你拦在门外，根本不需要惊动后面的Redis和数据库。此外，即使数据库真的查不到数据，Redis也会顺手把这个“空结果”缓存一小会儿，防止同一个无效请求反复骚扰数据库。

第二个挑战：缓存击穿（学霸助手刚好去上厕所了）
缓存击穿针对的是某一个极其热门的“爆款商品”。平时大家都在问这个商品的信息，Redis都能秒回。但恰好在这一瞬间，这个商品的缓存过期了（或者因为某些原因失效了）。此时，成千上万原本能直接拿到答案的请求，发现缓存没了，于是一窝蜂地全部涌向数据库去查询。这种单点的瞬时高压，极易把数据库打挂。
如何防护？ 最经典的办法是加一把“互斥锁”。当缓存失效时，只允许一个请求去问数据库，其他请求必须在外面排队等待。等这唯一的请求把新数据带回缓存后，排队的请求就可以直接从缓存中获取答案了。另一种更极致的策略是“热点数据永不过期”，对于这种超级爆款，干脆不让Redis里的数据过期，而是通过后台任务悄悄地去更新它，从而彻底杜绝失效的瞬间。

第三个挑战：缓存雪崩（整个办公室突然停电了）
缓存雪崩比前两者更可怕，它指的是大规模的缓存Key在同一时间集中过期，或者整个Redis集群直接宕机。这就好比“学霸助手”团队集体罢工或办公室突然停电，所有积压的请求瞬间全部压向“老教授”数据库。数据库根本没有能力承接这种全量的洪峰，最终导致整个系统全面瘫痪。
如何防护？ 针对集中过期，我们可以在给数据设置过期时间时，人为地加上一个随机的偏移量（比如在1小时的基础上随机加0到5分钟），让缓存失效的时间均匀散开，避免“扎堆”失效。针对Redis宕机，我们需要建立多级缓存体系。比如在应用服务器的本地内存里再放一份热点数据（本地缓存）。即使远程的Redis集群出了问题，本地缓存依然能临时顶住大部分流量，为系统抢修争取宝贵的时间。

结语
从穿透到雪崩，Redis在秒杀场景下的防护本质上是一场关于“概率”与“冗余”的博弈。通过布隆过滤器拦截无效请求、通过互斥锁和永不过期保护热点数据、通过随机过期和多级缓存分散系统风险，我们才能在高并发的洪流中，守住系统稳定运行的底线。理解这些概念，不仅是后端开发的必修课，更是理解现代互联网架构高可用设计的核心钥匙。