这篇文章主要讲解了“如何理解Redis雪崩、击穿、穿透、预热、降级”，文中的讲解内容简单清晰，易于学习与理解，下面请大家跟着小编的思路慢慢深入，一起来研究和学习“如何理解Redis雪崩、击穿、穿透、预热、降级”吧！
缓存击穿根据名字根本无法看懂是什么意思，并且很容易和另一个词——缓存穿透搞混。缓存击穿指的是某个 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添加到缓存中。
当访问量突然剧增（例如下班的点，大家都在地铁上刷手机呢）、服务出现问题（如响应时间慢或不响应）或非核心服务影响到核心流程的性能时，仍然需要保证服务还是可用的，即使是有损服务。
系统可以根据一些关键数据进行自动降级，降级的最终目的是保证核心服务可用，即使是有损的。但是有的一些业务的核心服务是不能降级的。这是一种丢卒保帅的思想。
感谢各位的阅读，以上就是“如何理解Redis雪崩、击穿、穿透、预热、降级”的内容了，经过本文的学习后，相信大家对如何理解Redis雪崩、击穿、穿透、预热、降级这一问题有了更深刻的体会，具体使用情况还需要大家实践验证。这里是亿速云，小编将为大家推送更多相关知识点的文章，欢迎关注！
免责声明：本站发布的内容（图片、视频和文字）以原创、转载和分享为主，文章观点不代表本网站立场，如果涉及侵权请联系站长邮箱：is@yisu.com进行举报，并提供相关证据，一经查实，将立刻删除涉嫌侵权内容。
