Redis缓存穿透、缓存击穿、缓存雪崩及其多种处理方式详解

空城旧守i

已于 2022-01-21 20:58:28 修改

阅读量1.6k

点赞数 12

分类专栏： Redis 数据库 Java进阶文章标签： redis 缓存 java

于 2021-11-27 00:34:37 首次发布

本文链接：https://blog.csdn.net/qq_52355487/article/details/121570252

版权

Java进阶同时被 3 个专栏收录

10 篇文章 1 订阅

订阅专栏

数据库

5 篇文章 0 订阅

订阅专栏

Redis

3 篇文章 0 订阅

订阅专栏

文章目录

一、缓存穿透（数据查不到）
二、缓存击穿（访问量太大，缓存正好过期）
三、缓存雪崩（缓存集体过期）

一、缓存穿透（数据查不到）

1.概念

当用户想要查询一个数据时，发现redis内存数据库没有，也就是缓存没有命中，于是向持久层数据库查询。发现也没有，于是本次查询失败。当用户很多时，缓存都没有命中，于是都去请求了持久层数据库。缓存本就是为了减轻数据库压力，这样redis形同虚设，这给持久层数据库造成很大的压力，这时候就相当于出现了缓存穿透。

2.解决方案

（1）解决方案一：缓存空对象

当存储层没有查询到后，即使返回的空对象也将其缓存起来，同时会设置一个过期时间（这里缓存不存在key的时候一定要设置过期时间，不然当数据库已经新增了这一条记录的时候，会导致缓存和数据库不一致的情况），之后再访问这个数据将会从缓存中获取，若我为空，就不会再去访问持久层数据库，保护了后端数据源，防止了攻击用户反复用同一个id暴力攻击。

请添加图片描述
但有两种问题：

如果空值被缓存起来，这就意味着缓存需要更多的空间存储更多的键
即使对空值设置了过期时间，还是会在缓存层和存储层的数据会有一段时间窗口的不一致，这对于需要保持一致性的业务会有影响。

（2）解决方案二：布隆过滤器

布隆过滤器是一种数据结构，对所有可能查询的参数以hash形式存储，同时引入一种节省空间的数据结构，位图（bitmap），他是一个有序的数组，只有两个值，0 和 1。0代表不存在，1代表存在。在控制层先进行校验，不符合则丢弃，从而避免了对底层存储系统的查询压力。
请添加图片描述
事实上布隆过滤器并不是百分百过滤的，由于哈希冲突与位图特性，会出现误判情况，即将不存在的通过计算，误判为存在，这种情况被称为假阳性（False Positive Probability，FPP），但其出现的机率很小，默认为0.03，所以布隆过滤器不是万能的，但是它能帮我们抵挡掉大部分不存在的数据已经很不错了，已经减轻数据库很多压力了。

从容器的角度来说：

如果布隆过滤器判断元素在集合中存在，不一定存在

如果布隆过滤器判断不存在，一定不存在

从元素的角度来说：

如果元素实际存在，布隆过滤器一定判断存在

如果元素实际不存在，布隆过滤器可能判断存在

二、缓存击穿（访问量太大，缓存正好过期）

1.概述

这里需要注意和缓存击穿的区别，是指一个key非常热点，在不停扛着高并发，高并发集中对这一个点进行访问，当这个key在过期的瞬间，持续的高并发就会穿破缓存，直接请求数据库，就像在一个屏障上凿了一个洞。
当某个key在过期的瞬间，就会有大量的请求并发访问，这类数据一般是热点数据，由于缓存过期，会同时访问数据库来查询最新数据，并且回写缓存，会导致数据库瞬间压力增大

2.解决方案

（1）解决方案一：永不过期

顾名思义，将key设置为永不过期，这样就不会出现缓存过期的情况。但是随着永久的key越来越多，可能对服务器的压力也会不断增大。

优点：不会出现缓存击穿
缺点：key逐渐增多，如果不常使用，会造成服务器资源浪费，增大服务器压力。

（2）解决方案二：加互斥锁

业界比较常用的做法，是使用mutex。简单地来说，就是在缓存失效的时候（判断拿出来的值为空），不是立即去查询持久层数据库，而是先使用缓存工具的某些带成功操作返回值的操作（比如Redis的SETNX，也就是只有不存在的时候才设置，可以利用它来实现锁的效果）去set一个mutex key，当操作返回成功时，再进行查询持久层数据库的操作并回设缓存。否则，就重试整个get缓存的方法。
用浅显易懂的语言来说，就是如果有多个线程同时去访问缓存中同一个key，但是这个key并不存在，所以使用setnx先设置一个key，设置成功的那个线程然后就去持久层数据库拿数据，而其他线程使用setnx再设置这个key时，其已经存在，就会设置失败而被拦截，让他过一会再重新get这个key。等到那个线程从持久层数据库拿来值，并把key-value放入缓存中后，其他线程就能直接获取到缓存中正确的key。

代码如下：

public String get(key) { 
    String value = redis.get(key);
    	if (value == null) { // 缓存已过期
            //对其设置3分钟过期时间防止delete失败导致下次过期无法使用
        	if (redis.setnx(key_mutex, 1, 3 * 60) == 1) {// 设置成功
            	value = db.get(key); 
                redis.set(key,value,expire_secs);
            	redis.del(key_mutex); 
        	} else {// 其他线程已load db并回设缓存，重试获取缓存即可
            	sleep(50);
            	get(key); //重试 
            } 
        }else { // 缓存未过期
            return value; 
        }
    } 
 }

优点：思路简单，保持一致性
缺点：代码更加复杂，存在死锁风险，存在线程池阻塞风险

（3）解决方案三：异步重建缓存——“提前“互斥锁

我们也可以把过期时间存在key对应的value里，其值比真实过期时间早一些，如果发现要过期了 通过一个后台的异步线程对缓存进行重新构建。 其与永不过期类似，但若该key一直没有访问，就会正常过期，不会占用内存，如果高并发访问，也能一直维持不过期。

代码如下：

String get(final String key) {  
        V v = redis.get(key);  
        String value = v.getValue();  
        long timeout = v.getTimeout();  
        if (v.timeout <= System.currentTimeMillis()) {  
            // 异步更新后台异常执行  
            threadPool.execute(new Runnable() {  
                public void run() {  
                    String keyMutex = "mutex:" + key;  
                    if (redis.setnx(keyMutex, 1，3 * 60)) {  
                        // 对其设置3分钟过期时间防止delete失败导致下次过期无法使用
                        String dbValue = db.get(key);  
                        redis.set(key, dbValue);  
                        redis.delete(keyMutex);  
                    }  
                }  
            });  
        }  
        return value;  
}

优点：异步构建缓存，不会阻塞线程池
缺点：不保证一致性，非构建缓存线程可能访问老数据，代码复杂度增大且占用一定的内存空间(每个value都要维护一个timekey)

三、缓存雪崩（缓存集体过期）

1.概述

缓存雪崩，是指在某一个时间段，缓存集中过期失效，导致请求全部转发到数据库，使数据库瞬间压力过大而导致雪崩。但这并不是最致命的，最致命的是断电断网或Redis服务器宕机。这对服务器造成的压力是不可预知的，很有可能瞬间就把数据库压垮，当然这是突发情况，只能通过高可用来解决，服务器宕机后，立即让其他服务器接替，而不影响正常业务的开展。