06-Redis 高频面试题 缓存的【雪崩-击穿-穿透】鲜为人知的秘密

「本文已参与好文召集令活动，点击查看：后端、大前端双赛道投稿，2万元奖池等你挑战！」

前言

你们好，我是飓风

往期文章索引以下：

00-Redis 你真的了解吗？
01-Redis 数据类型你知道的不止这些
02-Redis 哈希表的门道
03-Redis 凭什么这么快
04-Redis 持久化AOF你真的了解吗？
05-Redis 持久化之RDB 的奥秘

前面的文章咱们主要聊了一些redis 的基础知识，一直没有实战或者实际中遇到的问题，你们会枯燥无味些，今天我就来聊聊实战。

• 缓存雪崩
• 缓存击穿
• 缓存穿透

相信这三个问题，网上已经有不少的伙伴讲过了，可是今天我仍是想说下，会多画图，让你们加深印象，这三个问题也高频的面试题，可是能把这几个问题说清楚，也是须要技巧的。

再说这三个问题的时候，先说下正常的请求流程，看图说话：

上图的意思大体以下：

首先会在你的代码中，多是tomcat 也能够是你的rpc 服务中，先判断缓存cache 中是否存在你想要的数据，若是存储了，那么直接返回给调用端，若是不存在，那么就须要查询数据库，查询出结果来，再继续缓存到cache中，而后返回结果给调用方，下次再来的查询的时候，也就命中缓存了。

缓存雪崩

定义

记得以前在作推荐系统的时候，有些数据是离线算法算出来的，需求是看了这个商品会推荐哪些类似的商品，这个算出来以后会存储到hbase，同时存储到redis，因为都是批量算法出来的，再存储到redis 的时候，若是过时时间设置相同，那么就会形成大批量的key ，在同一时刻失效，那么就会有大批量的请求会被打到后台的数据库上，由于数据库的吞吐量是有限的，颇有可能会把数据库打垮的，这种状况就是缓存雪崩，看图说话：

这个主要是说明一个缓存雪崩出现的场景，尤为是定时任务在批量设置cache的时候，必定要注意过时时间的设置。

如何预防雪崩

其实也很简单，就是在你批量设置cache的缓存时间的时候，给设置的缓存时间，设置一个随机数(如随机数能够10分钟内的数字，随机数的生成能够用java的Random生成)，这样，就不会出现大量的key，再同一时刻集体失效了，看图说话：

若是真的发生了雪崩怎么办？

流量不是很大，数据库能抗住，ok，恭喜你逃过一劫。

流量很大，超过了数据库所能处理的请求数的极限，数据库down机了，也恭喜你领了一个P0事故单。

流量很大，若是你的数据库有限流方案，当达到了限流设置的参数，那么就会拒绝请求，从而保护了后台db。这里对限流多说几句。

能够经过设置每秒请求数，来限制大量的请求到达db端，注意这里的每秒请求数，或者说是并发数，并非数据当前的每秒请求数，能够设置为查询某个key 对应的每秒请求数量，这样作的目的，是防止大量相同key的请求到达后端数据库，这样就能拦截了大部分请求了。

看图说话：

这样相同的key，就会被限流了大部分请求，从而保护了数据库db。

其实限流还分为本地限流和分布式限流两种，后面的文章里，我会 介绍本地限流和redis 实现的分布式限流。

缓存击穿

定义

好比在某网站在进行双十一或者在搞秒杀等运营活动的时候，那么此时网站流量通常都会很大的，某个一个商品由于促销会成为爆品，流量超级的大，若是这个商品，在这个时候，因为某种缘由，在cache内失效了，那么就瞬间这个key的流量都会涌向数据库了，那么db最终挺不住了，down了，后果可想而知啊，正常其余的数据也查询不了。

看图说话：

redis 中的huawei pro 这个key 忽然失效了，多是到期了，多是内存不够被淘汰了，那么就会有大流量的请求到达redis ，发现redis 没有这个key，那么这些流量，就会转到DB 上去，查询对应的huawei pro，此时DB 挺不住了，down了。

如何解决

其实归根到底仍是不能让更多的流量到达DB就好了，因此咱们就是要限制到达db的流量就能够了。

一、限流

和上面说的相似，主要是限制某个key的流量，当这个key ，被击穿后，限制只有一个流量进入到db，其余都被拒绝，或者等待重试查询redis。

限流的图能够参考缓存击穿限流的图。

这里也会分本地限流和分布式限流 。

何为本地限流，就是在本地单个实例范围内，限制这个key的流量多少，只对当前实例有效。
何为分布式限流呢，就是在分布式的环境下，多个实例的范围内，这个key的限制流量的累加是来自多个实例的流量，达到限制，全部的实例都会限制流量到达DB。

二、利用分布式锁

这里简单说下分布式锁的定义，在并发场景下，须要使用锁对共享资源互斥访问来保证线程安全；一样，在分布式场景下，也须要一种机制来保证对多节点共享资源的互斥访问，实现机制就是分布式锁。

在这里共享资源就是例子中的huawei pro，也就是在访问db中的huawei pro 的时候，要保证只有一个线程或者一个流量去访问，就达到了分布式锁的效果。

看图说话：

去抢锁：

大量请求在没有获取到huawei pro 这个key的值后，准备去db获取数据，此时获取db的代码加了分布式锁，那么每一个请求，也是每一个线程都会去获取huawei pro 的分布式锁(图中利用redis实现了分布式锁，后面我会有单独一篇文章来介绍分布式锁的实现，不限于redis)。

获取锁以后：

此时线程A获取了huawei pro 的分布式锁，那么线程A就会去DB加载数据，而后由线程A将huawei pro 再次设置到cache内，而后返回数据。

其余的线程就没有获取到，一种方式就是直接返回空值给客户端，还有一种等待50-100ms ，由于查询db和放入redis 会很快，此时等待，再次查询的时候，结果可能就有了，若是没有就直接返回null，固然也能够重试，固然在大并发的场景下，仍是但愿可以快速的返回结果，不能发生太屡次数的重试操做。

三、定时任务更新热点key

这个就很好理解，说白了，就是一个定时任务定时的去监控某些热点key的超时时间，是否到期，再进行快到期了的时候延长key在cache中的缓存时间就能够了。

单个线程轮询的方式检查和更新失效时间,看图：

多线程的方式，注意热点的key 不能太多，某个线程会开启不少，若是热点key不少，能够采用线程池的方式，看图：

延迟队列实现

上面的方式说白了，不管是单个线程仍是多个线程，都是会采用轮询的方式（每次白白浪费的cpu），来检查是否key 快到期了，这种方式检查会存在检查时间不许确，可能会形成时间的延迟或者不许确，你在等待进行下次检查的时候，这个key就没了，那么此时就已经发了击穿，这个状况的发生虽然几率低，但也是有的，那么咱们怎么才能避免呢，其实我们能够利用延迟队列(环形队列来实现，这里我不深刻讲这个队列的原理了，你们能够自行百度或者google)，所谓的延迟队列就是你往这个队列发送消息，但愿按照你设置的时间来进行消费，时间没到不会进行消费，时间到了就进行消费，好了，看图说话吧：

一、程序首次启动 获取名单内key的失效时间。
二、依次设置key 延迟消费的时间，注意这个消费时间要比失效时间要早。
三、延迟队列到期，消费端进行消费key。
四、消费端消费消息，延迟key的失效时间到cache。
五、再次发送key 新的失效时间到延迟队列，等待下次延迟cache的失效时间。

四、设置key 不失效

这种其实也可能会由于内存不足，key 被淘汰，你们能够想一想什么状况下，key 会被淘汰。

缓存穿透

定义

所谓穿透，就是访问了一个cache不存在，数据库里也不存在的key，那么此时至关于流量直接到达了DB 了，那么一些流氓就能够利用这个漏洞，疯狂的刷你的接口，进而把你的DB打垮，你的业务也就不能正常运行了。

如何解决呢？

一、设置null 或者特殊值

咱们能够经过设置null 或者特定的值到redis内，且不过时，那么下次再来的时候，直接从redis 获取这个null 或者 特殊值就能够了。

这个方案不能解决根本性的问题，若是这个流量能仿造出大量的无用key，你设置再多的null或者特殊的值都是没有用的，那么咱们应该怎么解决呢？

二、布隆过滤器

布隆过滤器 英文为 bloomfiler，这里咱们只是作简单的介绍，介于篇幅的缘由，后面会有单独的文章作介绍。
举个例子，若是咱们数据库里存储着千万级别的sku 数据，咱们如今的需求是若是库有这个sku，那么就查询redis ，若是redis 没有就查询数据库，而后更新redis，咱们最早想到的就是把sku数据放入到一hashmap内，key 就是sku，由于sku 的数量不少，那么这个hashmap占用的内存空间会很大，有可能会撑爆内存，最后得不偿失了，那么怎么来节省内存，咱们能够利用一个bit的数组，来存储这个sku是否存在状态，0 表明不存在，1 表明存在，咱们能够利用一个散列函数，算出sku的散列值，而后sku的散列值对bit数组进行取模，找到所在数组的位置，而后设置为1，当请求来的时候，咱们会算出这个sku 散列值对应的数组位置是否为1 ，为1 说明就存在，为0 说明就不存在。这样一个简单的bloomfilter就实现了，bloomfiler 是有错误率，能够考虑增长数组长度和散列函数的数量来提供准确率，具体能够百度或者google，今天在这里就不讲了。

下面看看利用bloomfiler 来防止缓存穿透的流程，看图说话：

bloomfiler的初始化 能够经过一个定时任务来读取 db，初始化bit数组的大小，默认值都是为0，表示不存在，而后每条都计算散列值对应的数组位置，而后插入到bit 数组中。

请求流程，看图：

若是不利用bloomfiler 过滤器，对于一个数据库里根本不存在的key，其实白白浪费了两次IO，一次查询redis，一次查询DB，有了bloomfiler ，那么就节省了这两次无用的IO，减小后端redis 和 DB 资源的浪费。

总结

今天咱们聊了redis缓存 的高频的面试和实战中遇到的问题以及解决方案。

• 缓存雪崩

解决方案：

1. 在设置失效时间段的时候，加上一个时间的随机数，能够几分钟以内的均可以。
2. 以及若是真的雪崩了怎么办的问题，能够采用限流的方式。

• 缓存击穿

解决方案：

1. 限流
2. 分布式锁
3. 定时更新热点key ，这里重点看下延迟队列。
4. 设置时间不失效

• 缓存穿透

解决方案：

1. 设置null 或者特定的值到redis
2. 使用bloomfiler实现

---

今天的分享就到这里了，码字画图不易，期待你的点赞、关注、转发，谢谢。

你的点赞、关注 是飓风创做的最大动力。

若有问题 欢迎人才请留言，一块儿讨论和勘误。

欢迎关注 github

微信添加: zookeeper0