缓存之缓存穿透、缓存击穿、缓存雪崩

痛定思痛。 2022-02-15 07:37 473阅读 0赞

**目录**

概述

一、缓存处理流程

二、缓存穿透

三、缓存击穿

四、缓存雪崩

--------------------

### 概述 ###

什么样的数据适合缓存？

分析一个数据是否适合缓存,我们要从访问频率、读写比例、数据一致性等要求去分析.

![è¿éåå¾çæè¿°][70]

### 一、缓存处理流程 ###

前台请求，后台先从缓存中取数据，取到直接返回结果，取不到时从数据库中取，数据库取到更新缓存，并返回结果，数据库也没取到，那直接返回空结果。

![70 1][]

### 二、缓存穿透 ###

**描述：**

缓存穿透是指缓存和数据库中都没有的数据，而用户不断发起请求，如发起为id为“-1”的数据或id为特别大不存在的数据。这时的用户很可能是攻击者，攻击会导致数据库压力过大。简单的说，就是访问一个不存在的key，缓存不起作用，请求会穿透到DB，流量大时DB会挂掉。

**解决方案：**

1）接口层增加校验，如用户鉴权校验，id做基础校验，id<=0的直接拦截；  
2）从缓存取不到的数据，在数据库中也没有取到，这时也可以将key-value对写为key-null，缓存有效时间可以设置短点，如30秒（设置太长会导致正常情况也没法使用）。这样可以防止攻击用户反复用同一个id暴力攻击

3）采用布隆过滤器，使用一个足够大的bitmap，用于存储可能访问的key，不存在的key直接被过滤；

### 三、缓存击穿 ###

**描述：**

缓存击穿是指缓存中没有但数据库中有的数据（一般是缓存时间到期），这时由于并发用户特别多，同时读缓存没读到数据，又同时去数据库去取数据，引起数据库压力瞬间增大，造成过大压力。简单说就是：一个存在的key，在缓存过期的一刻，同时有大量的请求，这些请求都会击穿到DB，造成瞬时DB请求量大、压力骤增。

**解决方案：**

方案一

后台刷新

> 后台定义一个job(定时任务)专门主动更新缓存数据.比如,一个缓存中的数据过期时间是30分钟,那么job每隔29分钟定时刷新数据(将从数据库中查到的数据更新到缓存中).

*  这种方案比较容易理解，但会增加系统复杂度。比较适合那些 key 相对固定,cache 粒度较大的业务，key 比较分散的则不太适合，实现起来也比较复杂。

方案二

检查更新

> 将缓存key的过期时间(绝对时间)一起保存到缓存中(可以拼接,可以添加新字段,可以采用单独的key保存..不管用什么方式,只要两者建立好关联关系就行).在每次执行get操作后,都将get出来的缓存过期时间与当前系统时间做一个对比,如果缓存过期时间-当前系统时间<=1分钟(自定义的一个值),则主动更新缓存.这样就能保证缓存中的数据始终是最新的(和方案一一样,让数据不过期.)

*  这种方案在特殊情况下也会有问题。假设缓存过期时间是12:00，而 11:59   
    到 12:00这 1 分钟时间里恰好没有 get 请求过来，又恰好请求都在 11:30 分的时   
    候高并发过来，那就悲剧了。这种情况比较极端，但并不是没有可能。因为“高   
    并发”也可能是阶段性在某个时间点爆发。

方案三

分级缓存

> 采用 L1 (一级缓存)和 L2(二级缓存) 缓存方式，L1 缓存失效时间短，L2 缓存失效时间长。 请求优先从 L1 缓存获取数据，如果 L1缓存未命中则加锁，只有 1 个线程获取到锁,这个线程再从数据库中读取数据并将数据再更新到到 L1 缓存和 L2 缓存中，而其他线程依旧从 L2 缓存获取数据并返回。

*  这种方式，主要是通过避免缓存同时失效并结合锁机制实现。所以，当数据更   
    新时，只能淘汰 L1 缓存，不能同时将 L1 和 L2 中的缓存同时淘汰。L2 缓存中   
    可能会存在脏数据，需要业务能够容忍这种短时间的不一致。而且，这种方案   
    可能会造成额外的缓存空间浪费。

方案四

加锁

方法1

1.  `// 方法1:`
2.  `public synchronized List<String> getData01() {`
3.  `List<String> result = new ArrayList<String>();`
4.  `// 从缓存读取数据`
5.  `result = getDataFromCache();`
6.  `if (result.isEmpty()) {`
7.  `// 从数据库查询数据`
8.  `result = getDataFromDB();`
9.  `// 将查询到的数据写入缓存`
10. `setDataToCache(result);`
11. `}`
12. `return result;`
13. `}`

*  这种方式确实能够防止缓存失效时高并发到数据库,但是缓存没有失效的时候,在从缓存中拿数据时需要排队取锁,这必然会大大的降低了系统的吞吐量.

方法2

1.  `// 方法2:`
2.  `static Object lock = new Object();`
3.   
4.  `public List<String> getData02() {`
5.  `List<String> result = new ArrayList<String>();`
6.  `// 从缓存读取数据`
7.  `result = getDataFromCache();`
8.  `if (result.isEmpty()) {`
9.  `synchronized (lock) {`
10. `// 从数据库查询数据`
11. `result = getDataFromDB();`
12. `// 将查询到的数据写入缓存`
13. `setDataToCache(result);`
14. `}`
15. `}`
16. `return result;`
17. `}`

*  这个方法在缓存命中的时候,系统的吞吐量不会受影响,但是当缓存失效时,请求还是会打到数据库,只不过不是高并发而是阻塞而已.但是,这样会造成用户体验不佳,并且还给数据库带来额外压力.

方法3

1.  `//方法3`
2.  `public List<String> getData03() {`
3.  `List<String> result = new ArrayList<String>();`
4.  `// 从缓存读取数据`
5.  `result = getDataFromCache();`
6.  `if (result.isEmpty()) {`
7.  `synchronized (lock) {`
8.  `//双重判断,第二个以及之后的请求不必去找数据库,直接命中缓存`
9.  `// 查询缓存`
10. `result = getDataFromCache();`
11. `if (result.isEmpty()) {`
12. `// 从数据库查询数据`
13. `result = getDataFromDB();`
14. `// 将查询到的数据写入缓存`
15. `setDataToCache(result);`
16. `}`
17. `}`
18. `}`
19. `return result;`
20. `}`

双重判断虽然能够阻止高并发请求打到数据库,但是第二个以及之后的请求在命中缓存时,还是排队进行的.比如,当30个请求一起并发过来,在双重判断时,第一个请求去数据库查询并更新缓存数据,剩下的29个请求则是依次排队取缓存中取数据.请求排在后面的用户的体验会不爽.

方法4

1.  `static Lock reenLock = new ReentrantLock();`
2.   
3.  `public List<String> getData04() throws InterruptedException {`
4.  `List<String> result = new ArrayList<String>();`
5.  `// 从缓存读取数据`
6.  `result = getDataFromCache();`
7.  `if (result.isEmpty()) {`
8.  `if (reenLock.tryLock()) {`
9.  `try {`
10. `System.out.println("我拿到锁了,从DB获取数据库后写入缓存");`
11. `// 从数据库查询数据`
12. `result = getDataFromDB();`
13. `// 将查询到的数据写入缓存`
14. `setDataToCache(result);`
15. `} finally {`
16. `reenLock.unlock();// 释放锁`
17. `}`
18.  
19. `} else {`
20. `result = getDataFromCache();// 先查一下缓存`
21. `if (result.isEmpty()) {`
22. `System.out.println("我没拿到锁,缓存也没数据,先小憩一下");`
23. `Thread.sleep(100);// 小憩一会儿`
24. `return getData04();// 重试`
25. `}`
26. `}`
27. `}`
28. `return result;`
29. `}`

*  最后使用互斥锁的方式来实现，可以有效避免前面几种问题.

当然,在实际分布式场景中，我们还可以使用 redis、tair、zookeeper 等提供的分布式锁来实现.但是,如果我们的并发量如果只有几千的话,何必杀鸡焉用牛刀呢?

与上合并，待做？

加互斥锁，最好对同一key加互斥锁

互斥锁参考代码如下：  
         ![70 2][]

说明：

1）缓存中有数据，直接走上述代码13行后就返回结果了

2）缓存中没有数据，第1个进入的线程，获取锁并从数据库去取数据，没释放锁之前，其他并行进入的线程会等待100ms，再重新去缓存取数据。这样就防止都去数据库重复取数据，重复往缓存中更新数据情况出现。

3）当然这是简化处理，理论上如果能根据key值加锁就更好了，就是线程A从数据库取key1的数据并不妨碍线程B取key2的数据，上面代码明显做不到这点。

方案五

设置热点数据永远不过期。

方案六

在访问key之前，采用SETNX（set if not exists）来设置另一个短期key来锁住当前key的访问，访问结束再删除该短期key。

### 四、缓存雪崩 ###

**描述：**

缓存雪崩是指缓存中数据大批量到过期时间，而查询数据量巨大，引起数据库压力过大甚至down机。和缓存击穿不同的是，  缓存击穿指并发查同一条数据，缓存雪崩是不同数据都过期了，很多数据都查不到从而查数据库。

** 解决方案：**

1）缓存数据的过期时间设置随机，防止同一时间大量数据过期现象发生。  
2）如果缓存数据库是分布式部署，将热点数据均匀分布在不同搞得缓存数据库中。  
3）设置热点数据永远不过期。

[70]: /images/20220215/39817e99b29745ea84ead4e2cee65b82.png
[70 1]: /images/20220215/e7c068d3172d432e8bd38a3eee39fec5.png
[70 2]: /images/20220215/0bb2512eaec8433a9f26aec604839fc1.png