一篇文章搞清楚Redis 缓存预热,缓存击穿,缓存雪崩,缓存穿透。


前言

我们一般的系统,在达到一定QPS之后,都会启用缓存来抗压。而大部分缓存解决方案都是用的redis。
Redis具有简单,稳定,数据可持久化等特点。得到了很多公司的实际应用。
使用Redis 在达到一定的业务场景的时候,就会出现我们经常在面试中遇到的关于缓存的几个问题。
缓存预热,缓存穿透,缓存击穿,缓存雪崩


一、缓存预热

直面意思上来说,以APP作为例子。就是在用户还没打开我们APP之前。就已经把数据库里面的热点数据放入到缓存中了。这样用户在进入APP的时候,请求的是缓存的里面的记录。这样就极大的减少了对于数据库的压力。造成缓存击穿

实际场景: 我们有一款APP,每次准点会推送一些PUSH消息。这样很多用户在1分钟之内大量进入APP,导致并发量瞬间突增。如果所有的瞬时流量全部集中到数据库中,会导致系统整体压力非常大。所以这个时候在用户进去之前必须对首页的数据进行缓存预热。这样再大的压力也只会集中打到服务器和Redis上面。

总结:缓存预热就是提前给用户准备好饭菜。用户进系统不用等待(等待数据库查询),直接就能开吃

二、缓存穿透

假如我们认为缓存是一堵墙,然后墙后面是我们的数据库。我们在业务场景中,对于热点数据应该要做到所有的请求都打在这堵墙上,对于数据库尽量减少请求。缓存穿透的意思就是绕过了这堵墙,访问了在缓存中一定查询不到的数据,这样就会把所有的请求打到数据库,从而造成了数据库的压力。

实际场景:我们对于用户ID,针对每个用户ID,每请求一次会对用户信息生成一个缓存,缓存key值就是用户的ID值。但是当我们把用户ID换成-1进行请求,因为我们的用户ID肯定是会大于0的,所以如果有这样的请求,我们在缓存里面铁定查不到这条数据。就会把所有的请求打到数据里面,造成一次查询,增加数据库压力。

解决方案:针对数据库查询为空的数据,也进行缓存。缓存时间设置小点。或者设置边界值。上述场景 针对ID小于0的请求,直接报错,不让请求。

三、缓存击穿

假如我们认为缓存是一堵墙,然后墙后面是我们的数据库。击穿直面意思就是把墙的某一点打穿了。那这个点肯定是热点数据。由于这个key一直被大量请求。突然这个缓存失效了,一下子就会把大量的压力给到了数据库。造成系统崩溃。

实际场景:微博热搜就是这样的一个真实场景,随时随地都会有大量的请求在微博热搜上面。如果这个时候微博热搜缓存突然失效。这个时候所有压力都在数据库上面,就会造成数据库压力突增,系统崩溃。

解决方案:针对热点数据永不过期。热点数据只能我们去替换。让其永不过期。

四、缓存雪崩

假如我们认为缓存是一堵墙,然后墙后面是我们的数据库。然后每块砖是一个缓存key。假定用户每进行一次请求。我们会生成一次缓存。添一块砖。这样下次请求的压力也是在砖上。但由于我们缓存是有过期时间的。如果突然所有的砖在同一时刻全部崩塌。那这个时候一瞬间所有的请求又都会在数据库上面。造成数据库压力过大崩溃。

实际场景:在商品抢购,一波商品时间比较集中的放入缓存中,假设缓存设置一个小时,当过期时间到达后,这批商品会统一失效,而对于这批商品的访问查询,会直接落到数据库上,对于数据库而言,就会产生周期性的压力波峰,甚至会造成数据库宕掉。

解决方案:
1 针对key值设置随机过期时间,避免key值集中某一时间批量失效。
2 redis灾备。防止使用中redis主机崩溃导致系统崩溃
3 服务降级 优先提供核心服务

  • 0
    点赞
  • 2
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

程序员若风+

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值