一文搞懂什么是缓存穿透、缓存雪崩、缓存击穿三个概念,以及解决方案

发布时间:2024年01月01日

先理解概念:【注:我们这里说的是分布式、高并发环境】
一、缓存穿透是什么?

缓存穿透是指:请求【可以有很多】的数据在缓存、关系型数据库中都不存在,每次来查询都会查询到关系型数据库中。

在这里插入图片描述

解决方案:
1、将空对象缓存到Redis:
简单的说就是第一次如果去关系型数据库查询回来如果为空,就将将空值也缓存到Redis(如:set keyxxx null),可以将过期时间设置短一点,避免大量的null值占用内存,如遇到key值饱和攻击将会是很大的麻烦,内存会被这些空值大量占用。

优点:实现简单。
缺点:不存在的key-value占用内存;高并发环境多个线程同时访问,可能存在缓存过期前或者刷缓存前查询都为空,返回不了真实数据。

2、使用布隆过滤器
所谓布隆过滤器就是一个很大的bitmap,由二进制向量表和一系列随机映射函数组成。里面并不存放真实的数据,里面只是标识位(0/1),某个key在hash过后来查不用过滤器返回为0就表示数据库不存在该数据,直接给请求返回为空就行,有值就是1,然后就可以查询缓存服务器,或者去查关系型数据库了。实现方案(redisson+redis,redisson本来就封装好了布隆过滤器、guava、fpp都可以)。

------------------->>>> redisson方案:
<dependencies>
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-data-redis</artifactId>
    </dependency>
 
    <dependency>
        <groupId>org.redisson</groupId>
        <artifactId>redisson-spring-boot-starter</artifactId>
        <version>3.13.0</version>
    </dependency>
</dependencies>

------------------->>>> guava方案:

<dependency>
  <groupId>com.google.guava</groupId>
  <artifactId>guava</artifactId>
  <version>29.0-jre</version>
</dependency>

优点:布隆过滤器内存占用较少;
缺点:实现相对复杂一丢丢、布隆过滤器存在误判【原因是hash冲突,如果key的hash值相同,就会引起本来没值的key判断成了有值,去查Redis或者MySQL】。

二、缓存击穿是什么?

缓存击穿:指一个被高并发访问且缓存重建业务较复杂的key突然失效了,无数查询这个key的请求瞬间会直接打在关系型数据库上,给数据库带来了巨大的压力,通常也叫热点Key问题
在这里插入图片描述

解决方案:

1、互斥锁

高并发环境,避免缓存不存在这个key的数据,然后多个线程并发的去访问数据库,我们需要在查询缓存结束,没有数据后,在查询数据库前需要设置一道分布式锁,拿到锁的才可以执行后续逻辑,拿不到的可以让他等待一段时间重试缓存是否有数据,这里不能重试查询关系型数据库哦【这里锁的设置需要考虑:锁的可重入、可重试、锁的超时释放、锁的主从一致性】。

2、逻辑过期

key的失效多数是由于到了过期时间的key被清理,而新的该key的缓存还没建立,而此时来了大量请求,那我们是不是可以:设置该key不主动失效、分布式锁解决。
a、key不主动失效,不是不主动失效,可以利用Redis的hash结构将过期时间拼接在value里面(如:hset product_01 1000 timestamp ),用户自己去决定这个key是否过期删除,类似于Redis的key的惰性删除原理,如果有请求过来,查询该key时候,会有一次检查过期时间的操作,如果过期了就先加锁,暂时阻塞其他线程访问数据库,然后删除该缓存,接着再请求数据库写入缓存,释放锁【只能删除自己的锁】,返回数据,其他线程可以查询缓存返回数据库了。这里有可能存在极端情况就是在更新缓存期间,其他线程等待时间过长,直接返回空数据回去。这里也可以考虑MQ异步的去更新缓存哦。

三、缓存雪崩

缓存雪崩:是指同一时段内缓存中大量的key同时失效或者缓存服务器宕机,导致大量请求打在关系型数据库上,关系型数据库有可能瞬间被打死。【通常8c16g的mysql数据库,单台主库2000次/s并发写是可以扛住的,从库8c16g可以达到5000多qps】

在这里插入图片描述

解决方案:

1、key同时段失效的情况:
a、 给key的过期时间设置随机值,比如说选择:60s~600s,随机一个数字为过期时间。
b、多级缓存,然后设置不同的过期时间;
c、结合网关、hystrix/sentinel 限流,大批量的请求不用全都放过来,可以允许一部分请求一次失败,让客户重试,比如:抢购、抢红包;
d、结合MQ,请求直接先放到MQ里面,异步的查询Redis或者关系型数据库,异步返回数据,消费者慢慢消费,几乎也都可以做到毫秒或者秒级的返回,高并发的环境,一般用户等待个几秒钟都是可以接受的,不用追求极致,也需要在成本、用户体验、性能、可用性之间做个平衡,作为架构师应该要考虑到这些问题。

2、缓存服务器宕机的情况
这个要尽可能的实现缓存服务的高可用了,不管是缓存的:主从+哨兵、分片+主从+哨兵、集群(一致性hash结构/避免hash倾斜的增加虚拟节点的结构)+哨兵+主从等结构,都可以。注意:主从节点一般都是至少三个节点,且最好是奇数个节点,避免集群选举出现脑裂或者票数一半一半,选不出来,qurom=半数节点以上,majority=存活实例数/2+1。

文章来源:https://blog.csdn.net/qq_35543206/article/details/135325953
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。