文章详情

短信预约-IT技能 免费直播动态提醒

请输入下面的图形验证码

提交验证

短信预约提醒成功

Redis中缓存雪崩、缓存击穿和缓存穿透的示例分析

2024-04-02 19:55

关注

这篇文章主要为大家展示了“Redis中缓存雪崩、缓存击穿和缓存穿透的示例分析”,内容简而易懂,条理清晰,希望能够帮助大家解决疑惑,下面让小编带领大家一起研究并学习一下“Redis中缓存雪崩、缓存击穿和缓存穿透的示例分析”这篇文章吧。

Redis中缓存雪崩、缓存击穿和缓存穿透的示例分析

相信这三个问题,网上已经有很多的伙伴讲过了,但是今天我还是想说下,会多画图,让大家加深印象,这三个问题也高频的面试题,但是能把这几个问题说清楚,也是需要技巧的。

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

Redis中缓存雪崩、缓存击穿和缓存穿透的示例分析

上图的意思大致如下:

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

缓存雪崩

定义

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

Redis中缓存雪崩、缓存击穿和缓存穿透的示例分析

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

如何预防雪崩

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

Redis中缓存雪崩、缓存击穿和缓存穿透的示例分析

如果真的发生了雪崩怎么办?

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

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

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

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

看图说话:

Redis中缓存雪崩、缓存击穿和缓存穿透的示例分析

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

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

缓存击穿

定义

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

看图说话:

Redis中缓存雪崩、缓存击穿和缓存穿透的示例分析

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

如何解决

其实归根到底还是不能让更多的流量到达DB就行了,所以我们就是要限制到达db的流量就可以了。

1、限流

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

限流的图可以参考缓存击穿限流的图。

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

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

2、利用分布式锁

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

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

看图说话:

去抢锁:

Redis中缓存雪崩、缓存击穿和缓存穿透的示例分析

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

获取锁之后:

Redis中缓存雪崩、缓存击穿和缓存穿透的示例分析

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

其他的线程就没有获取到,一种方式就是直接返回空值给客户端,还有一种等待50-100ms ,因为查询db和放入redis 会很快,此时等待,再次查询的时候,结果可能就有了,如果没有就直接返回null,当然也可以重试,当然在大并发的场景下,还是希望能够快速的返回结果,不能发生太多次数的重试操作。

3、定时任务更新热点key

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

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

Redis中缓存雪崩、缓存击穿和缓存穿透的示例分析

多线程的方式,注意热点的key 不能太多,某个线程会开启很多,如果热点key很多,可以采用线程池的方式,看图:

Redis中缓存雪崩、缓存击穿和缓存穿透的示例分析

延迟队列实现

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

Redis中缓存雪崩、缓存击穿和缓存穿透的示例分析

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

4、设置key 不失效

这种其实也可能会因为内存不足,key 被淘汰,大家可以想想什么情况下,key 会被淘汰。

缓存穿透

定义

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

如何解决呢?

1、设置null 或者特殊值

我们可以通过设置null 或者特定的值到redis内,且不过期,那么下次再来的时候,直接从redis 获取这个null 或者 特殊值就可以了。

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

2、布隆过滤器

布隆过滤器 英文为 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 数组中。

Redis中缓存雪崩、缓存击穿和缓存穿透的示例分析

请求流程,看图:

Redis中缓存雪崩、缓存击穿和缓存穿透的示例分析

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

总结

缓存雪崩

解决方案:

缓存击穿

解决方案:

缓存穿透

解决方案:

以上是“Redis中缓存雪崩、缓存击穿和缓存穿透的示例分析”这篇文章的所有内容,感谢各位的阅读!相信大家都有了一定的了解,希望分享的内容对大家有所帮助,如果还想学习更多知识,欢迎关注亿速云行业资讯频道!

阅读原文内容投诉

免责声明:

① 本站未注明“稿件来源”的信息均来自网络整理。其文字、图片和音视频稿件的所属权归原作者所有。本站收集整理出于非商业性的教育和科研之目的,并不意味着本站赞同其观点或证实其内容的真实性。仅作为临时的测试数据,供内部测试之用。本站并未授权任何人以任何方式主动获取本站任何信息。

② 本站未注明“稿件来源”的临时测试数据将在测试完成后最终做删除处理。有问题或投稿请发送至: 邮箱/279061341@qq.com QQ/279061341

软考中级精品资料免费领

  • 历年真题答案解析
  • 备考技巧名师总结
  • 高频考点精准押题
  • 2024年上半年信息系统项目管理师第二批次真题及答案解析(完整版)

    难度     813人已做
    查看
  • 【考后总结】2024年5月26日信息系统项目管理师第2批次考情分析

    难度     354人已做
    查看
  • 【考后总结】2024年5月25日信息系统项目管理师第1批次考情分析

    难度     318人已做
    查看
  • 2024年上半年软考高项第一、二批次真题考点汇总(完整版)

    难度     435人已做
    查看
  • 2024年上半年系统架构设计师考试综合知识真题

    难度     224人已做
    查看

相关文章

发现更多好内容

猜你喜欢

AI推送时光机
位置:首页-资讯-数据库
咦!没有更多了?去看看其它编程学习网 内容吧
首页课程
资料下载
问答资讯