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

关于 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<CharSequence> 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"));

    }

}

结果

完。

等等……缓存穿透、预热、降级你还没说呢。哦，我真的以为本文结束了。

那布隆过滤器是如何解决缓存穿透的问题的呢？既然已经知道了布隆过滤器的原理，那么就可以通过布隆过滤器来快速的判断出一个key是否存在数据库中，如果可能存在再去数据库查询，如果布隆过滤器中不存在那么就需要再去数据库查询了。

缓存预热

这又是什么鬼？怎么搞一个缓存还有这么多问题，那还要缓存干啥？

所谓缓存预热就是将一些可能经常使用数据在系统启动的时候预先设置到缓存中，这样可以避免在使用到的时候先去数据库中查询。

这就是缓存预热，名气高大上，实际上很简单有木有，这个缓存预热我在实际场景是经常使用的。

还有一种方式就是添加一个缓存刷新页，这样通过人工干预的方式将一些可能为热点的key添加到缓存中。

缓存降级

当访问量突然剧增（例如下班的点，大家都在地铁上刷手机呢）、服务出现问题（如响应时间慢或不响应）或非核心服务影响到核心流程的性能时，仍然需要保证服务还是可用的，即使是有损服务。

系统可以根据一些关键数据进行自动降级，降级的最终目的是保证核心服务可用，即使是有损的。但是有的一些业务的核心服务是不能降级的。这是一种丢卒保帅的思想。

结束语

关于技术的学习，大家除了为了应付面试去短期强行的记忆一些知识点外，我还是建议各位在学习阶段能够循序渐进。小孩子从出生到走路一般还有10个月呢，要想会说话时间就更长。

但是这个过程必须是有的，因为小孩子需要一点一点来适应这个未知的世界。我们作为成年人在学习的时候也要保持这种平静心态，有些事情急是没用的。

最后以一句不畏艰险，勇攀高峰来和大家共勉。