Redis突然被击穿了，背后到底藏着啥问题让它撑不住了？

“Redis突然被击穿了，背后到底藏着啥问题让它撑不住了？”

这事儿得从一个常见的场景说起,想象一下，你的网站有一个热门商品，比如最新款的手机，马上就要开抢了，成千上万的用户挤在页面前，不停地刷新，这个手机的商品信息就存在Redis里，因为它快，能顶住高并发。

突然,这个Redis里的手机数据因为某种原因消失了，可能是过期时间到了自动删除了，也可能是网络波动导致数据丢了，或者干脆是Redis服务本身重启了一下。（来源：常见的缓存失效场景）

这下可好,第一个用户的请求过来，发现Redis里没数据，很自然地，它就会直接去查后面的数据库，数据库老老实实地把手机信息查出来，准备塞回Redis，好让后面的请求能直接从缓存里取，听起来好像没问题，对吧？

但坏就坏在,这不是一个用户在请求，这是成千上万个请求像潮水一样涌过来，当这成千上万个请求在同一时刻，都发现Redis里没有这个热门数据时，会发生什么？（来源：高并发场景下的缓存击穿描述）

它们不会排队,也不会商量，而是会一窝蜂地全部冲向后端的数据库去查询这条不存在于缓存里的数据，数据库本来就是个“文官”，处理读写请求是按部就班的，它的并发承受能力远远比不上Redis这种“武将”，瞬间，数据库上就堆积了成千上万个相同的查询请求。

这就好比一个狭窄的收费站,平时车流平稳，突然涌来几百辆车都要同时通过，结果就是彻底堵死，谁也动不了。（来源：用比喻解释数据库压力）

数据库的CPU使用率瞬间飙到100%，连接数被占满，新的请求根本进不来，更可怕的是，这些查询都是同一条SQL语句：“SELECT * FROM products WHERE id = ‘热门手机ID’”，数据库要重复执行成千上万次一模一样的、毫无意义的查询，这对其资源是极大的浪费。

由于数据库被这些“缓存击穿”带来的洪水般请求打趴下了，它无法正常响应其他业务请求，用户会发现，不仅那个手机页面打不开，连网站的其他功能，比如登录、查看订单、浏览其他商品等，全都变得极慢甚至完全失败，这就是典型的由单点故障引发的系统性崩溃。

到底是什么问题导致了Redis“撑不住”了这个局面呢？其实Redis本身可能运行得好好的，问题出在“缓存失效”和“高并发请求”这两个条件同时被满足的设计缺陷上。

缓存键的过期时间设置可能不合理，对于这种极端热门的数据，如果设置了固定的、并且在同一时刻过期的过期时间，就像埋下了一个定时炸弹，一旦到期，所有请求就会同时被引向数据库。（来源：对缓存过期策略的反思）

也是更核心的问题,系统缺乏一种有效的“锁”机制来防止大量并发请求穿透到数据库，一个健壮的系统，当发现缓存失效时，应该只允许一个请求线程去数据库查询数据，然后重建缓存，而其他后续的请求应该被暂时挡住，等待第一个请求把数据塞回Redis后，直接从Redis中获取结果。（来源：解决缓存击穿的互斥锁方案思想）

但很多系统在初期设计时,可能没预料到会有如此巨大的并发量，或者为了追求极致的简单性，忽略了这个保护措施，还有一种情况是，所谓的“锁”没设计好，比如用了分布式锁但性能太差，或者锁的粒度不对，反而成了瓶颈。

还有一个容易被忽视的点是,对缓存的管理不够细致，对于一些永远不会变化的基础数据，或者可以容忍长时间不更新的数据，其实可以设置为“永不过期”，然后通过后台任务或者事件触发来主动更新它，从而避免被动失效带来的风险。（来源：缓存更新策略的多样性）

Redis被击穿,表面上看是Redis里没数据了，根子上其实是系统在应对“缓存失效”这一常态事件时，缺乏一道坚固的“防洪坝”，当海量请求涌来时，这道防线一旦缺失，压力就会毫无缓冲地直接砸在相对脆弱的数据库上，最终导致整个系统的雪崩，解决之道，就在于如何巧妙地设计这道“坝”，比如用互斥锁、异步更新、热点数据永不过期等多种策略组合起来，才能让系统真正地扛住风雨。