redis_缓存三大问题

一、redis_缓存雪崩

正常流程:

Redis_什么是缓存雪崩、缓存穿透、缓存击穿?

缓存雪崩:

Redis_什么是缓存雪崩、缓存穿透、缓存击穿?

实际上,缓存雪崩描述的就是这样一个简单的场景:缓存在同一时间大面积的失效,后面的请求都直接落到了数据库上,造成数据库短时间内承受大量请求。 这就好比雪崩一样,摧枯拉朽之势,数据库的压力可想而知,可能直接就被这么多请求弄宕机了。

情景举例1:

系统的缓存模块出了问题比如宕机导致不可用。造成系统的所有访问,都要走数据库。

情景举例2:

有一些被大量访问数据(热点缓存)在某一时刻大面积失效,导致对应的请求直接落到了数据库上。

秒杀开始 12 个小时之前,我们统一存放了一批商品到 Redis 中,设置的缓存过期时间也是 12 个小时,那么秒杀开始的时候,这些秒杀的商品的访问直接就失效了。导致的情况就是,相应的请求直接就落到了数据库上,就像雪崩一样可怕。

解决措施1:针对 Redis 服务不可用的情况:
  1. 采用 Redis 集群,避免单机出现问题整个缓存服务都没办法使用。
  2. 限流,避免同时处理大量的请求。
解决措施2:针对热点缓存失效的情况:
  1. 设置不同的失效时间比如随机设置缓存的失效时间。
  2. 缓存永不失效。

二、redis_缓存穿透

缓存穿透:

Redis_什么是缓存雪崩、缓存穿透、缓存击穿?

缓存穿透说简单点就是大量请求的 key 根本不存在于缓存中,导致请求直接到了数据库上,根本没有经过缓存这一层。举个例子:某个黑客故意制造我们缓存中不存在的 key 发起大量请求,导致大量请求落到数据库。

解决措施1:参数校验

最基本的就是首先做好参数校验,一些不合法的参数请求直接抛出异常信息返回给客户端。比如查询的数据库 id 不能小于 0、传入的邮箱格式不对的时候直接返回错误消息给客户端等等。

解决措施2:缓存无效 key

如果缓存和数据库都查不到某个 key 的数据就写一个到 Redis 中去并设置过期时间,具体命令如下: SET key value EX 10086 。这种方式可以解决请求的 key 变化不频繁的情况,如果黑客恶意攻击,每次构建不同的请求 key,会导致 Redis 中缓存大量无效的 key 。很明显,这种方案并不能从根本上解决此问题。如果非要用这种方式来解决穿透问题的话,尽量将无效的 key 的过期时间设置短一点比如 1 分钟。

解决措施3:布隆过滤器

通过它我们可以非常方便地判断一个给定数据是否存在于海量数据中。我们需要的就是判断 key 是否合法,有没有感觉布隆过滤器就是我们想要找的那个“人”。

具体是这样做的:把所有可能存在的请求的值都存放在布隆过滤器中,当用户请求过来,先判断用户发来的请求的值是否存在于布隆过滤器中。不存在的话,直接返回请求参数错误信息给客户端,存在的话才会走下面的流程。
Redis_什么是缓存雪崩、缓存穿透、缓存击穿?

但是,需要注意的是布隆过滤器可能会存在误判的情况。总结来说就是: 布隆过滤器说某个元素存在,小概率会误判。布隆过滤器说某个元素不在,那么这个元素一定不在。

Redis_什么是缓存雪崩、缓存穿透、缓存击穿?
为什么会出现误判的情况呢? 我们还要从布隆过滤器的原理来说!

我们先来看一下,当一个元素加入布隆过滤器中的时候,会进行哪些操作:

  1. 使用布隆过滤器中的哈希函数对元素值进行计算,得到哈希值(有几个哈希函数得到几个哈希值)。
  2. 根据得到的哈希值,在位数组中把对应下标的值置为 1。

我们再来看一下,当我们需要判断一个元素是否存在于布隆过滤器的时候,会进行哪些操作:

  1. 对给定元素再次进行相同的哈希计算;
  2. 得到值之后判断位数组中的每个元素是否都为 1,如果值都为 1,那么说明这个值在布隆过滤器中,如果存在一个值不为 1,说明该元素不在布隆过滤器中。

然后,一定会出现这样一种情况:不同的字符串可能哈希出来的位置相同。

三、 redis_缓存击穿

缓存击穿:

Redis_什么是缓存雪崩、缓存穿透、缓存击穿?

某一热点key突然失效,导致大量该key的请求打到数据库,引起数据库异常。

解决措施1:缓存不过期
解决措施2:使用分布式锁

在redis缓存找不到时,在redis与数据库直接使用分布式锁,这样在同一时间只有一个线程拿到这把锁,其他用户没有拿到锁,就只有等待。同样拿到锁的用户线程能访问数据库,当查找到相应的值时,同步更新到redis缓存中,此时别的用户线程进redis缓存中就可进行查找了~

分类:

技术点:

相关文章: