老生常谈的 Redis 雪崩、击穿、穿透、预热、降级一次全安排

发表于 3年以前 | 总阅读数：344 次

关于 Redis 的介绍、特点什么的就不再这里赘述了，不然又要水千把字。今天我们就重点看企业中在使用 Redis 常见一些问题以及对应解决方案。

某个请求到达业务系统，想要获取某个数据，一般是先从缓存中获取，如果缓存中不存在就会去数据库中查询，如果查询到结果就将数据保存到缓存中再返回结果。

一个新的技术的引进，必然会带来一些额外的问题，那么 Redis 这么优秀的 NoSQL 数据库会带来什么样的问题呢？我们一起拭目以待。

缓存击穿

缓存击穿根据名字根本无法看懂是什么意思，并且很容易和另一个词——缓存穿透搞混。缓存击穿指的是某个 key 一直在扛着高并发，所谓扛着高并发就是说大量的请求都是获取这个 key 对应的值。

而这个 key 在某个时间突然失效了，那是不是就意味着大量的请求就无法在缓存中获取数据了，而是去请求数据库了，这样很有可能导致数据库被击垮。这就是缓存击穿。

那现在问题知道了，该如何应对呢？这个就比较简单了，既然这个 key 这个受欢迎，那么就不要设置过期时间了，如果该key的数据更新了，那么就通过互斥锁的方式将其更新。

为什么要用互斥锁的方式？如果不使用互斥锁的方式很容易导致数据不一致的情况，这里为了保证缓存和数据库的一致性，就只能牺牲一点点的效率了。

缓存雪崩

不知道各位小伙伴都是来自哪里，我们那边有句方言叫“雪崩”，表示事情砸了的意思。这里的Redis 雪崩似乎有点异曲同工之妙。首先我们需要知道什么是 Redis雪崩，

Redis雪崩我们一般都称为缓存雪崩，意思就是说在某个时间节点，大量的 key 失效，导致大量的请求从缓存中获取不到数据而去请求数据库。根据上面的那张图，我们再来画下雪崩的情况的是什么样子的：

上面的黑色的部分表示缓存无效了，也就意味着所有的请求都需要到数据库中去查询数据。那这对于数据库的压力必然是剧增的，如果是在一线互联网这样超高并发的场景下，数据库直接宕机。

重启也没有用，因为重启了还会有巨大的流量涌进来，然后继续被搞宕机。所以对于预防缓存雪崩这种情况的发生意义还是很大的的。

缓存雪崩解决方案之加随机值

上面已经详细介绍了什么是缓存雪崩，他是怎么发生的，那如果防止缓存雪崩呢？

很简单，因为上面刚刚说到，缓存雪崩是由于某个时间节点大量的 key 失效而导致的问题，那现在的问题不就是变成了如何防止同一个时间节点大量的 key 失效这种情况发生吗？

最简单的情况就是把key的过期时间分散开，也就是在设置key的过期时间的时候再加一个随机值，就这样就能完美的解决缓存雪崩的问题。

但是你以为我说到这里就完事了？既然是一次全安排，那么我一定不会仅仅告诉你一种解决方案就完事的。继续看

缓存雪崩解决方案之加锁

可能很多人看到这个方案表示不接受，加锁那不是限制了并发？加锁必然导致阻塞。如果是加锁，那么执行就成就是这个样子了：

流程是这样子的，在多个请求同时到达业务系统时候，只能有一个线程能获取到锁，然后才能继续去缓存或者是数据库中查询数据，然后后面的流程和之前的是一样的，执行完成后释放锁，然后其他线程再争抢锁，然后重复前面的流程。

这个方案的优点是可以很好的保护数据库不会被打挂，缺点就是并发度极低。

上面这个方案其实还是可以再优化下的：

这个就是在缓存中如果获取不到，再去串行的访问数据看，这里不一定非要串行，可以配合线程池，控制一定的并发数。

这个缺点虽然很多，但是也是一种解决方案。用不用就看实际的业务场景了。毕竟没有没用技术方案，只有不适合业务场景的技术方案（手动狗头）。

缓存穿透

缓存穿透意思就是某个不存在的key一直被访问，结果发现数据库中也没有这样的数据，最终导致访问该key的所有请求都直接请求到数据库了。如果是并发高的场景下就容易搞垮数据库。大家有没有发现我们做的一些事情都是在保护“弱小的数据库”。

那现在问题已经知道了，我们该如何去解决这个问题呢？

缓存穿透解决方案之缓存空数据

啥叫缓存空数据？就是假设某个key数据并不存在，那么就存一个 NULL 就好了，但是一定不要忘记设置过期时间，因为假设id=3的记录不存在，然后本次访问没有查询到数据，缓存中存的是null如果过一会儿新增了一条记录为3的数据，如果缓存不设置过期时间，那么这条数据就永远获取不到。

缓存穿透解决方案之布隆过滤器

布隆过滤器？这玩意到底什么意思？

布隆过滤器是一种数据结构，更准确的说是一种概率型的数据结构，因为它能判断某个元素一定不存在或者是可能存在。

就这句话，搞蒙了很多人，今天我非要把你说明白了。布隆过滤器是一个bit数组，一个很长的bit数组和一系列的hash函数构成。先看下图

我们现在来举个例子，假设现在有小强和旺财两个人，他们分别经过三次hash得到的下标是这样子的（布隆过滤器不存储元素，仅仅是为一个元素是否存在打一个标志）

小强经过上面的三个hash后得到的下标分别为：2、4、5，那么该数组的2、4、5位置就会被置为1，也就是此时是这样子的

同样旺财经过上面的三个hash后得到的下标分别为：3、7、11，那么该数组的3、7、11位置就会被置为1，也就是此时是这样子的

现在假设来一个 007 经过上面的三个hash后得到的下标分别为：11、13、15因为13、和15位置是0，所以一定可以判断007 一定不存在。但是现在又来了一个

9527经过上面的三个hash后得到的下标分别为：2、5、7，但是你会发现257三个位置全部是1，那这个到底说明9527是存在还是不存在呢？

从我们上面的讲解可以 9527 之前并不存在，但是由于hash冲突，但是9527的三个下标值也刚好落在已经被置为1的下标位置，这就导致此时是无法判断9527是否存在的。这就是布隆过滤器的原理。

要不来段代码压压惊？

我们来使用 google 包下的类来测试。首先要添加依赖

<dependency>

    <groupId>com.google.guava</groupId>

    <artifactId>guava</artifactId>

    <version>30.1-jre</version>

</dependency>

代码如下（详细的解释我已经写在注释中了，这个是可以用于实际生产的代码）

public class BloomFilterDemo {

    public static void main(String[] args) {

        /**

         * 创建一个插入对象为一亿，误报率为0.01%的布隆过滤器

         * 不存在一定不存在

         * 存在不一定存在

         */

        BloomFilter&lt;CharSequence&gt; bloomFilter = BloomFilter.create(Funnels.stringFunnel(Charset.forName("utf-8")),

                100000000,

                0.0001);

        bloomFilter.put("死");

        bloomFilter.put("磕");

        bloomFilter.put("Redis");

        System.out.println(bloomFilter.mightContain("Redis"));

        System.out.println(bloomFilter.mightContain("死"));

        System.out.println(bloomFilter.mightContain("磕"));

        System.out.println(bloomFilter.mightContain("Java"));

    }

}

结果