高并发下缓存失效的三个问题-穿透、雪崩、击穿

╰+哭是因爲堅強的太久メ 2023-10-11 18:32 12阅读 0赞

![a75db408041c4c7287755c4952838621.png][]这篇文章我们就谈谈Redis在实际项目中用作缓存时经常碰到的，也是经常面试的三大问题：缓存穿透、缓存击穿、缓存雪崩，以及这些问题的常用解决方法。

在介绍这三大问题之前，我们需要先了解Redis作为一个缓存中间件，在项目中是如何工作的。首先看一下在没有缓存中间件的时候的系统数据访问的架构图：

![e2c6a48bad564dc5921d8c00fc24c150.png][]

**客户端发起一个查询请求的时候，首先去缓存中查询，如果数据在缓存中存在，则直接将缓存中的数据返回给客户端；如果数据在缓存中不存在，则继续查询数据库，如果数据在数据库中存在，则将该数据放入缓存中，并返回给客户端，如果数据在数据库中也不存在，则直接返回null给客户端。**

## 什么是缓存穿透 ##

缓存穿透是指查询一个缓存中和数据库中都不存在的数据，导致每次查询这条数据都会透过缓存，直接查库，最后返回空。当用户使用这条不存在的数据疯狂发起查询请求的时候，对数据库造成的压力就非常大，甚至可能直接挂掉。这种情况的流程就变成下图这样了：

![b255d91cc2354a67a3a024fdece79ee8.png][]

#### 缓存穿透解决方案 ####

解决缓存穿透的方法一般有两种，**第一种是缓存空对象**，**第二种是使用布隆过滤器**。

第一种方法比较好理解，就是当数据库中查不到数据的时候，我缓存一个空对象，然后给这个空对象的缓存设置一个过期时间，这样下次再查询该数据的时候，就可以直接从缓存中拿到，从而达到了减小数据库压力的目的。但这种解决方式有两个缺点：（1）需要缓存层提供更多的内存空间来缓存这些空对象，当这种空对象很多的时候，就会浪费更多的内存；（2）会导致缓存层和存储层的数据不一致，即使在缓存空对象时给它设置了一个很短的过期时间，那也会导致这一段时间内的数据不一致问题。

第二种方案是使用**布隆过滤器**，这是比较推荐的方法。所谓布隆过滤器，就是一种数据结构，它是由一个长度为m bit的位数组与n个hash函数组成的数据结构，位数组中每个元素的初始值都是0。在初始化布隆过滤器时，会先将所有key进行n次hash运算，这样就可以得到n个位置，然后将这n个位置上的元素改为1。这样，就相当于把所有的key保存到了布隆过滤器中了。

举个例子，比如我们一共有3个key，我们对这3个key分别进行3次hash运算，key1经过三次hash运算后的结果分别为2/6/10，那么就把布隆过滤器中下标为2/6/10的元素值更新为1，然后再分别对key2和key3做同样操作，结果如下图：

![fc60518096c745789e8f8b4060ac956a.png][]

这样，当客户端查询时，也对查询的key做3次hash运算得到3个位置，然后看布隆过滤器中对应位置元素的值是否为1，如果所有对应位置元素的值都为1，就证明key在库中存在，则继续向下查询；如果3个位置中有任意一个位置的值不为1，那么就证明key在库中不存在，直接返回客户端空即可。如下图：

![a3418cf011374a45bbfe8b44643132ab.png][]

当客户端查询key4时，key4的3次hash运算中，有一个位置8的值为0，就说明key4在库中不存在，直接返回客户端空即可。

所以，布隆过滤器就相当于一个位于客户端与缓存层中间的拦截器一样，负责判断key是否在集合中存在。如下图：

![24f1923d3a0942d484f08e2e22853339.png][]

> **布隆过滤器的好处就是解决了第一种缓存空值的不足，但布隆过滤器也存在缺陷，首先，它有误判的可能，比如在上面客户端查询key4的图中，假如key4经过3次hash运算得到的位置分别是2/4/6，由于这3个位置的值都是1，所以，布隆过滤器就认为key4在库中存在，进而继续向下查询了。所以，布隆过滤器判断存在的key实际上可能是不存在的，但布隆过滤器判断不存在的key是一定不存在的。它的第二个缺点就是删除元素比较难，比如现在要删除key2这个元素，那么需要将2/7/11三个位置的元素值改为0，但这样就会影响到key1和key3的判断。**

#### 什么是缓存击穿 ####

缓存击穿是指当缓存中某个热点数据过期了，在该热点数据重新载入缓存之前，有大量的查询请求穿过缓存，直接查询数据库。这种情况会导致数据库压力瞬间骤增，造成大量请求阻塞，甚至直接挂掉。

![83f5e47627ee484ebfaec68783828e54.png][]

#### 缓存击穿解决方案 ####

解决缓存击穿的方法也有两种，第一种是**设置key永不过期**；第二种是**使用分布式锁**，保证同一时刻只能有一个查询请求重新加载热点数据到缓存中，这样，其他的线程只需等待该线程运行完毕，即可重新从Redis中获取数据。

第一种方式比较简单，在设置热点key的时候，不给key设置过期时间即可。不过还有另外一种方式也可以达到key不过期的目的，就是正常给key设置过期时间，不过在后台同时启一个定时任务去定时地更新这个缓存。

![cb4c3b95014f4394b2d08f4a4e53339b.png][]

第二种方式使用了**加锁**的方式，锁的对象就是key，这样，当大量查询同一个key的请求并发进来时，只能有一个请求获取到锁，然后获取到锁的线程查询数据库，然后将结果放入到缓存中，然后释放锁，此时，其他处于锁等待的请求即可继续执行，由于此时缓存中已经有了数据，所以直接从缓存中获取到数据返回，并不会查询数据库。

![7e7c961f0f984f3cbd4fe00feca3ac57.png][]

#### 什么是缓存雪崩 ####

缓存雪崩是指当缓存中有大量的key在同一时刻过期，或者Redis直接宕机了，导致大量的查询请求全部到达数据库，造成数据库查询压力骤增，甚至直接挂掉。

> 比如在双十一的时候，用户都会打开淘宝买东西，有的人是真的有需要买的，有的人就是凑个热闹，不管怎么样，这时候首页的压力就非常大了，为了满足所有用户都可以访问到数据，阿里的程序员们将首页数据缓存到redis里，并设置redis失效时间是12小时。我们知道redis是内存数据库，那访问速度，杠杠的啊。数据缓存后用户们买的很开心，程序员们也很开心，系统都还好着呢……慢慢的12个小时过去了，用户购物的热情不减啊，还是大量的用户请求在过来，然而首页redis缓存的数据全失效了，这时候redis里没有数据了，用户请求直接扑向数据库，数据库哪能扛得住啊，直接垮掉

![cd6b6f9ce23d9ec0ce9f7b61ac080180.png][]

## **如何应对缓存雪崩** ##

![70d9989785d41c035558cb1e8b3b9cc7.png][]

1. 首先要保证redis的高可用，可以使用redis cluster，开启redis持久化，redis之前要使用本地缓存，请求先走本地缓存，没找到再走redis  
2.如果还是出现了缓存雪崩，开启限流组件，比如每秒5000个请求，只让其中2000个请求走数据库，剩下3000个请求走降级，给用户返回一些服务器繁忙的提示之类的  
3.随机设置key的失效时间，避免大量的key同时失效，比如不要设置过期时间或把过期时间设置得很长，再比如运行定时任务，随时监控缓存情况，在失效前刷新进新的缓存  
4.设置热点数据永不过期，活动结束后删除，或者定期手动删除  
5.给数据加锁，当有线程请求不到数据时，其它的用户线程也无法请求数据，直到第一个线程拿到数据后，去redis缓存起来，其它的线程仍然走缓存拿数据  
6.缓存雪崩发生后，根据RDB或者AOF文件恢复缓存数据

[a75db408041c4c7287755c4952838621.png]: https://img-blog.csdnimg.cn/a75db408041c4c7287755c4952838621.png
[e2c6a48bad564dc5921d8c00fc24c150.png]: https://img-blog.csdnimg.cn/e2c6a48bad564dc5921d8c00fc24c150.png
[b255d91cc2354a67a3a024fdece79ee8.png]: https://img-blog.csdnimg.cn/b255d91cc2354a67a3a024fdece79ee8.png
[fc60518096c745789e8f8b4060ac956a.png]: https://img-blog.csdnimg.cn/fc60518096c745789e8f8b4060ac956a.png
[a3418cf011374a45bbfe8b44643132ab.png]: https://img-blog.csdnimg.cn/a3418cf011374a45bbfe8b44643132ab.png
[24f1923d3a0942d484f08e2e22853339.png]: https://img-blog.csdnimg.cn/24f1923d3a0942d484f08e2e22853339.png
[83f5e47627ee484ebfaec68783828e54.png]: https://img-blog.csdnimg.cn/83f5e47627ee484ebfaec68783828e54.png
[cb4c3b95014f4394b2d08f4a4e53339b.png]: https://img-blog.csdnimg.cn/cb4c3b95014f4394b2d08f4a4e53339b.png
[7e7c961f0f984f3cbd4fe00feca3ac57.png]: https://img-blog.csdnimg.cn/7e7c961f0f984f3cbd4fe00feca3ac57.png
[cd6b6f9ce23d9ec0ce9f7b61ac080180.png]: https://img-blog.csdnimg.cn/img_convert/cd6b6f9ce23d9ec0ce9f7b61ac080180.png
[70d9989785d41c035558cb1e8b3b9cc7.png]: https://img-blog.csdnimg.cn/img_convert/70d9989785d41c035558cb1e8b3b9cc7.png