Redis缓存击穿,缓存穿透,缓存雪崩,附解决方案

技术博客 (53) 2023-12-15 18:01:01

前言

在日常的项目中,缓存的使用场景是比较多的。缓存是分布式系统中的重要组件,主要解决在高并发、大数据场景下,热点数据访问的性能问题,提高性能的数据快速访问。本文以Redis作为缓存时,针对常见的缓存击穿、缓存穿透、缓存雪崩问题做简单地说明,并且提供有效的解决方案。

Redis缓存使用场景

Redis会把数据库中经常被查询的数据缓存起来,比如热点数据,这样当用户通过网站或APP来访问的时候,就不需要到数据库中去查询了,而是直接获取 Redis中的缓存数据,从而降低了后端数据库的读取压力。如果说用户查询的数据Redis中没有,此时用户的查询请求就会转到数据库,当数据库将数据返回给客户端时,同时会将数据缓存到 Redis中,这样用户再次读取时,就可以直接从Redis中获取数据。流程图如下所示:

Redis缓存击穿,缓存穿透,缓存雪崩,附解决方案 (https://mushiming.com/) 技术博客 第1张

Redis缓存穿透

缓存穿透是指用户恶意的发起大量请求去查询一个缓存(Redis)和数据库(DB)中都没有的数据,出于容错考虑从数据库(DB)查不到数据则不写入缓存(Redis)这将导致每个请求都要到数据库(DB)中查询,失去了缓存的意义,从而导致数据库因压力过大挂掉。

流程图如下所示:

Redis缓存击穿,缓存穿透,缓存雪崩,附解决方案 (https://mushiming.com/) 技术博客 第2张

解决方案

  1. 对空值缓存

上面我们也介绍了,之所以会发生穿透,是因为缓存中没有存储这些空数据的key,从而导致每次查询都到数据库去了。

那么我们就可以为这些key的值设置null丢到缓存里面去,后面再出现查询这个key 的请求的时候,直接返回null ,就不用在到数据库中去走一圈了。但是别忘了设置过期时间。

关键代码如下:

Redis缓存击穿,缓存穿透,缓存雪崩,附解决方案 (https://mushiming.com/) 技术博客 第3张

  1. 添加参数校验

我们可以在接口层添加校验,不合法的直接返回即可,没必要做后续的操作。

例如:使用bitmaps类型定义一个可以访问名单,名单id作为bitmaps的偏移量,每次访问时与bitmaps中的id进行比较,如果访问id不在bitmaps中,则进行拦截,不给其访问。

  1. 采用布隆过滤器

布隆过滤器(Bloom Filter),Bloom Filter 类似于一个hash set 用来判断某个元素(key)是否存在于某个集合中,不存在return就好了,存在就去查DB刷新缓存KV再return,它的优点是空间效率和查询时间都比一般算法快,缺点是有一定的误识别率和删除困难。

布隆过滤器的工作方式:

一个空的布隆过滤器是一个由m个二进制位构成的数组。

Redis缓存击穿,缓存穿透,缓存雪崩,附解决方案 (https://mushiming.com/) 技术博客 第4张

以上只是画了布隆过滤器的很小很小的一部分,实际布隆过滤器是非常大的数组(这里的大是指它的长度大,并不是指它所占的内存空间大)。

当一个数据进行存入布隆过滤器的时候,会经过若干个哈希函数进行哈希,得到对应的哈希值作为数组的下标,然后将初始化的位数组对应的下标的值修改为1,结果图如下:

Redis缓存击穿,缓存穿透,缓存雪崩,附解决方案 (https://mushiming.com/) 技术博客 第5张

当再次进行存入第二个值的时候,修改后的结果的原理图如下:

Redis缓存击穿,缓存穿透,缓存雪崩,附解决方案 (https://mushiming.com/) 技术博客 第6张

那么为什么会有误判率呢?

假设在我们多次存入值后,在布隆过滤器中存在x、y、z这三个值,布隆过滤器的存储结构图如下所示:

Redis缓存击穿,缓存穿透,缓存雪崩,附解决方案 (https://mushiming.com/) 技术博客 第7张

当我们要查询的时候,比如查询M这个数,实际中M这个数是不存在布隆过滤器中的,经过哈希函数计算后得到M的哈希值分别为1和7,结构原理图如下:

Redis缓存击穿,缓存穿透,缓存雪崩,附解决方案 (https://mushiming.com/) 技术博客 第8张

经过查询后,发现1和7位置所存储的值都为1,但是1和7的下标分别是X和Z经过计算后的下标位置的修改,该布隆过滤器中实际不存在M,那么布隆过滤器就会误判改值可能存在,因为布隆过滤器不存元素值,所以存在误判率。

那么为什么不能删除元素呢?

原因很简单,因为删除元素后,将对应元素的下标设置为零,可能别的元素的下标也引用改下标,这样别的元素的判断就会受到影响。

Redis缓存雪崩

缓存雪崩是指大量的应用请求无法在Redis缓存中进行处理,紧接着应用将大量请求发送到数据库层,导致数据库层的压力激增。

缓存雪崩一般是由两个原因导致的,应对方案也有所不同。第一个原因是:缓存中有大量数据同时过期,导致大量请求无法得到处理。第二个原因是:Redis 缓存实例发生故障宕机了,无法处理请求,这就会导致大量请求一下子积压到数据库层,从而发生缓存雪崩。

流程图如下所示:

Redis缓存击穿,缓存穿透,缓存雪崩,附解决方案 (https://mushiming.com/) 技术博客 第9张

解决方案

  1. 大量热点数据同时失效带来的缓存雪崩问题

避免热key同时失效

使用 EXPIRE命令给每个数据设置过期时间时,给这些数据的过期时间增加一个较小的随机数(例如,随机增加 1~3 分钟)。这样一来,不同数据的过期时间有所差别,但差别又不会太大。既避免了大量数据同时过期,同时也保证了这些数据基本在相近的时间失效,仍然能满足业务需求。

2. 服务降级

所谓的服务降级,是指发生缓存雪崩时,针对不同的数据采取不同的处理方式,例如:

  • 当业务应用访问的是非核心数据时,暂时停止从缓存中查询这些数据,而是直接返回预定义信息、空值或是错误信息;

  • 当业务应用访问的是核心数据时,仍然允许查询缓存,如果缓存缺失,也可以继续通过数据库读取。

这样一来,我们就避免了大量请求因缓存缺失,而积压到数据库系统,保证了数据库系统的正常运行。

3. Redis 缓存实例发生故障宕机带来的缓存雪崩问题

从事前预防的角度,我们可以通过主从节点的方式构建 Redis 缓存高可靠集群。如果 Redis缓存的主节点故障宕机了,从节点还可以切换成为主节点,继续提供缓存服务,避免了由于缓存实例宕机而导致的缓存雪崩问题。

如果实际业务系统真发生了Redis 缓存实例不可用的情况,我们可以在业务系统中实现服务熔断或请求限流机制。所谓的服务熔断,是指在发生缓存雪崩时,为了防止引发连锁的数据库雪崩,甚至是整个系统的崩溃,我们暂停业务应用对缓存系统的接口访问。

Redis缓存击穿

我们在平常高并发的系统中,大量的请求同时查询一个key时,假设此时这个key正好失效了,就会导致大量的请求都打到数据库上面去,这种现象我们称为击穿。

这么看缓存击穿和缓存雪崩有点像,但是又有一点不一样,缓存雪崩是因为大面积的缓存失效,打崩了DB,而缓存击穿不同的是「缓存击穿」是指一个Key非常热点,在不停的扛着大并发,大并发集中对这一个点进行访问,当这个Key在失效的瞬间,持续的大并发就穿破缓存,直接请求数据库,就像在一个完好无损的桶上凿开了一个洞,如下图所示:

Redis缓存击穿,缓存穿透,缓存雪崩,附解决方案 (https://mushiming.com/) 技术博客 第10张

解决方案

1. 热key不过期

  • 预先设置热门数据:在Redis高峰访问时期,提前设置热门数据到缓存中,对这些热key不设置失效时间,不过这样设置需要区分场景。

  • 实时调整:实时监控哪些数据热门,实时调整key过期时间。

2. 分布式锁

为了避免出现缓存击穿的情况,我们可以在第一个请求去查询数据库的时候对他加一个分布式锁,其余的查询请求都会被阻塞住,直到锁被释放,后面的线程进来发现已经有缓存了,就直接走缓存,从而保护数据库。但是也是由于它会阻塞其他的线程,此时系统吞吐量会下降。需要结合实际的业务去考虑是否要这么做。

关键代码如下:

Redis缓存击穿,缓存穿透,缓存雪崩,附解决方案 (https://mushiming.com/) 技术博客 第11张

总结

缓存击穿

key对应的数据存在,但在redis中过期,此时若有大量并发请求过来,这些请求发现缓存过期一般都会从后端DB加载数据并回设到缓存,这个时候大并发的请求可能会瞬间把后端DB压垮。一般通过互斥锁,热点数据永不过期,定时刷新过期时间等方法解决该问题。

缓存穿透

key对应的数据在数据源并不存在,每次针对此key的请求从缓存获取不到,请求都会到数据源,从而可能压垮数据源。比如用一个不存在的用户id获取用户信息,不论缓存还是数据库都没有,若黑客利用此漏洞进行攻击可能压垮数据库。一般通过对空数据进行缓存,布隆过滤器等方法解决该问题。

缓存雪崩

当缓存服务器重启或者大量缓存集中在某一个时间段失效,这样在失效的时候,也会给后端系统(比如DB)带来很大压力。一般通过加锁排队,设置过期时间随机值等方法解决该问题。

THE END

发表回复