【Redis】-缓存穿透、缓存雪崩、缓存击穿

最新推荐文章于 2024-03-21 21:57:15 发布

imperfectsam

最新推荐文章于 2024-03-21 21:57:15 发布

阅读量1.7k

点赞数 55

文章标签：缓存 redis spring

本文链接：https://blog.csdn.net/weixin_36531037/article/details/136644802

版权

提示：写完文章后，目录可以自动生成，如何生成可参考右边的帮助文档

文章目录

一、缓存穿透
二、缓存雪崩
三、缓存击穿（热点数据集中失效）

一、缓存穿透

在大多数互联网应用中，缓存的使用方式如下图所示：
在这里插入图片描述

当业务系统发起某一个查询请求时，首先判断缓存中是否有该数据；
如果缓存中存在，则直接返回数据；
如果缓存中不存在，则再查询数据库，然后返回数据。

了解了上述过程后，下面说说缓存穿透。

1、什么是缓存穿透？

业务系统要查询的数据根本就不存在！当业务系统发起查询时，按照上述流程，首先会前往缓存中查询，由于缓存中不存在，然后再前往数据库中查询。由于该数据压根就不存在，因此数据库也返回空。这就是缓存穿透。

综上所述：业务系统访问压根就不存在的数据，就称为缓存穿透。

2、缓存穿透的危害

如果存在海量请求查询压根就不存在的数据，那么这些海量请求都会落到数据库中，数据库压力剧增，可能会导致系统崩溃（你要知道，目前业务系统中最脆弱的就是 IO，稍微来点压力它就会崩溃，所以我们要想种种办法保护它）。

3、为什么会发生缓存穿透？

发生缓存穿透的原因有很多，一般为如下两种：

恶意攻击，故意营造大量不存在的数据请求我们的服务，由于缓存中并不存在这些数据，因此海量请求均落在数据库中，从而可能会导致数据库崩溃。
代码逻辑错误。这是程序员的锅，没啥好讲的，开发中一定要避免！

4、缓存穿透的解决方案

（1）缓存空数据

所以发生缓存穿透，是因为缓存中没有存储这些空数据的 key，导致这些请求全都打到数据库上。

那么，我们可以稍微修改一下业务系统的代码，将数据库查询结果为空的 key 也存储在缓存中。当后续又出现该 key 的查询请求时，缓存直接返回 null，而无需查询数据库。
在这里插入图片描述
存空对象会有两个问题：
第一，空值做了缓存，意味着缓存层中存了更多的键，需要更多的内存空间 (如果是攻击，问题更严重)，比较有效的方法是针对这类数据设置一个较短的过期时间，让其自动剔除。
第二，缓存层和存储层的数据会有一段时间窗口的不一致，可能会对业务有一定影响。例如过期时间设置为 5 分钟，如果此时存储层添加了这个数据，那此段时间就会出现缓存层和存储层数据的不一致，此时可以利用消息系统或者其他方式清除掉缓存层中的空对象。

（2）BloomFilter（布隆过滤器）

布隆过滤器的作用：

大数据去重，节省空间。当布隆过滤器说某个值存在时，这个值可能不存在；当它说某个值不存在的时，那就肯定不存在（布隆过滤器有一定的误判率）。

Redis布隆过滤器：

Redis 官方提供的布隆过滤器是 Redis4.0 提供了插件功能之后才正式登场的。布隆过滤器作为一个插件加载到 Redis Server 中。

布隆过滤器基本指令：

● bf.add 添加元素
● bf.exists 查询元素是否存在
● bf.madd 批量添加元素
● bf.mexists 查询多个元素


> bf.add codehole user1
(integer) 1
> bf.exists codehole user1
(integer) 1
> bf.madd codehole user2 user3 user4
1) (integer) 1
2) (integer) 1
3) (integer) 1
> bf.mexists codehole user1 user2 user5
1) (integer) 1
2) (integer) 1
3) (integer) 0

自定义布隆过滤器：

如果我们想要修改布隆过滤器的大小、错误率。可以使用 bf.reserver 指令

BF.RESERVE {key} {error_rate} {capacity}

● error_rate 是错误率，默认是 0.01
● capacity 是布隆过滤器位数组大小，默认是 100

布隆过滤器原理

向布隆过滤器中添加值的时候，会先使用多个 hash 函数对此值进行 hash 计算，一个hash得出一个整数的索引值，然后对位数组进行取模运算得到一个位置，多个 hash .也就取得多个不同的位置，然后在这些位置上进行置1，这也就完成了 add 操作。

查询布隆过滤器的值是否存在，同理拿到不同的的位置，然后判断这些位置的值是否都为1，如果存在一个或一个以上不为1的，则说明，该值并不存在，如果得到对应的位置的都为1，也不能说明这个值一定存在，有可能是因为其它值导致这些位为1的，所以我们程序对于布隆过滤器判断可能存在的值，还需要进一步验证。

如果位数组比较稀疏（也就是位数组较大），那么判断正确的概率就会很大，如果比较拥挤，判断的正确概率就比较低。

空间占用估计

计算最佳 hash 数量 k

$K = 0.7 * (l / n)$ ：n 是预计元素的数量，l 是位数组的长度

计算错误率 k

$f = 0.6185^{(l/n)}$ ： n 是预计元素的数量，l 是位数组的长度

如何进行设计？

它需要在缓存之前再加一道屏障，里面存储目前数据库中存在的所有 key，如下图所示：
在这里插入图片描述
当业务系统有查询请求的时候，首先去 BloomFilter 中查询该 key 是否存在。若不存在，则说明数据库中也不存在该数据，因此缓存都不要查了，直接返回 null。若存在，则继续执行后续的流程，先前往缓存中查询，缓存中没有的话再前往数据库中的查询。

这种方法适用于数据命中不高，数据相对固定实时性低（通常是数据集较大）的应用场景，代码维护较为复杂，但是缓存空间占用少。

（3）两种方案的比较

对于一些恶意攻击，查询的 key 往往各不相同，而且数据贼多。此时，第一种方案就显得提襟见肘了。因为它需要存储所有空数据的 key，而这些恶意攻击的 key 往往各不相同，而且同一个 key 往往只请求一次。因此即使缓存了这些空数据的 key，由于不再使用第二次，因此也起不了保护数据库的作用。
因此，对于空数据的 key 各不相同、key 重复请求概率低的场景而言，应该选择第二种方案。而对于空数据的 key 数量有限、key 重复请求概率较高的场景而言，应该选择第一种方案。

二、缓存雪崩

1、什么是缓存雪崩？

通过上文可知，缓存其实扮演了一个保护数据库的角色。它帮数据库抵挡大量的查询请求，从而避免脆弱的数据库受到伤害。

如果缓存因某种原因发生了宕机，那么原本被缓存抵挡的海量查询请求就会像疯狗一样涌向数据库。此时数据库如果抵挡不了这巨大的压力，它就会崩溃。

这就是缓存雪崩。

2、如何避免缓存雪崩？

（1）使用缓存集群，保证缓存高可用

和飞机都有多个引擎一样，如果缓存层设计成高可用的，即使个别节点、个别机器、甚至是机房宕掉，依然可以提供服务，例如前面介绍过的 Redis Sentinel 和 Redis Cluster 都实现了高可用。

（2）使用Hystrix

Hystrix 是一款开源的 “防雪崩工具”，它通过熔断、降级、限流三个手段来降低雪崩发生后的损失。

Hystrix 就是一个 Java 类库，它采用命令模式，每一项服务处理请求都有各自的处理器。所有的请求都要经过各自的处理器。处理器会记录当前服务的请求失败率。一旦发现当前服务的请求失败率达到预设的值，Hystrix 将会拒绝随后该服务的所有请求，直接返回一个预设的结果。这就是所谓的“熔断”。当经过一段时间后，Hystrix 会放行该服务的一部分请求，再次统计它的请求失败率。如果此时请求失败率符合预设值，则完全打开限流开关；如果请求失败率仍然很高，那么继续拒绝该服务的所有请求。这就是所谓的“限流”。而 Hystrix 向那些被拒绝的请求直接返回一个预设结果，被称为“降级”。

三、缓存击穿（热点数据集中失效）

1、什么是缓存击穿？

我们一般都会给缓存设定一个失效时间，过了失效时间后，该数据库会被缓存直接删除，从而一定程度上保证数据的实时性。

但是，对于一些请求量极高的热点数据而言，一旦过了有效时间，此刻将会有大量请求落在数据库上，从而可能会导致数据库崩溃。其过程如下图所示：
在这里插入图片描述

如果某一个热点数据失效，那么当再次有该数据的查询请求[req-1]时就会前往数据库查询。但是，从请求发往数据库，到该数据更新到缓存中的这段时间中，由于缓存中仍然没有该数据，因此这段时间内到达的查询请求都会落到数据库上，这将会对数据库造成巨大的压力。此外，当这些请求查询完成后，都会重复更新缓存。

2、解决方案

（1）互斥锁

此方法只允许一个线程重建缓存，其他线程等待重建缓存的线程执行完，重新从缓存获取数据即可，整个过程如图 :
在这里插入图片描述
当第一个数据库查询请求发起后，就将缓存中该数据上锁；此时到达缓存的其他查询请求将无法查询该字段，从而被阻塞等待；当第一个请求完成数据库查询，并将数据更新值缓存后，释放锁；此时其他被阻塞的查询请求将可以直接从缓存中查到该数据。

当某一个热点数据失效后，只有第一个数据库查询请求发往数据库，其余所有的查询请求均被阻塞，从而保护了数据库。但是，由于采用了互斥锁，其他请求将会阻塞等待，此时系统的吞吐量将会下降。这需要结合实际的业务考虑是否允许这么做。

互斥锁可以避免某一个热点数据失效导致数据库崩溃的问题，而在实际业务中，往往会存在一批热点数据同时失效的场景。那么，对于这种场景该如何防止数据库过载呢？

设置不同的失效时间

当我们向缓存中存储这些数据的时候，可以将他们的缓存失效时间错开。这样能够避免同时失效。如：在一个基础时间上加 / 减一个随机数，从而将这些缓存的失效时间错开

（2）永远不过期

“永远不过期” 包含两层意思：
从缓存层面来看，确实没有设置过期时间，所以不会出现热点 key 过期后产生的问题，也就是 “物理” 不过期。
从功能层面来看，为每个 value 设置一个逻辑过期时间，当发现超过逻辑过期时间后，会使用单独的线程去构建缓存。

整个过程如下图所示：
在这里插入图片描述
从实战看，此方法有效杜绝了热点 key 产生的问题，但唯一不足的就是重构缓存期间，会出现数据不一致的情况，这取决于应用方是否容忍这种不一致。

（3）两种方案的比较

● 互斥锁 (mutex key)：这种方案思路比较简单，但是存在一定的隐患，如果构建缓存过程出现问题或者时间较长，可能会存在死锁和线程池阻塞的风险，但是这种方法能够较好的降低后端存储负载并在一致性上做的比较好。
● “永远不过期”：这种方案由于没有设置真正的过期时间，实际上已经不存在热点 key 产生的一系列危害，但是会存在数据不一致的情况，同时代码复杂度会增大。