登录
首页 >  数据库 >  Redis

Redis:缓存穿透、缓存击穿、缓存雪崩?

来源:51cto

时间:2023-03-10 15:09:40 452浏览 收藏

一分耕耘,一分收获!既然都打开这篇《Redis:缓存穿透、缓存击穿、缓存雪崩?》,就坚持看下去,学下去吧!本文主要会给大家讲到缓存击穿、缓存雪崩、缓存穿透等等知识点,如果大家对本文有好的建议或者看到有不足之处,非常欢迎大家积极提出!在后续文章我会继续更新数据库相关的内容,希望对大家都有所帮助!

为什么要使用缓存

Redis:缓存穿透、缓存击穿、缓存雪崩?

我们做的每一个项目基本上刚开始都是一个很小的项目,每天的QPS很少,那个时候系统访问都是直接请求到数据库;后来项目越来越大,使用的人越来越多,每天对于数据库的压力剧增,为了保证“有效、有限的请求”访问到数据库,我们放大前置环节的逻辑和成本,所以缓存应运而生。

缓存的好处有以下两点:

  • 提高接口的响应时间和并发量;
  • 减轻数据库的压力。

但是,我们用到了缓存,就不得不考虑三个经典的场景:“缓存穿透”、“缓存击穿”、“缓存雪崩”。本文将介绍三种场景并给出合理的解决方案,如有异议,请进行友好的评论。

缓存穿透

正常情况下,一个请求过来,首先判断key是否存在,如果key存在,直接返回;如果key不存在或者已过期,查询数据库,如果数据库中存在数据,则更新缓存并返回数据;如果不存在,则直接返回空。

缓存穿透(cache penetration)是用户访问的key在数据库中一定不存在的数据,如果有人利用这个漏洞恶意攻击系统,每次请求的压力都给到数据库,会压垮数据库,造成系统崩溃。

Redis:缓存穿透、缓存击穿、缓存雪崩?

方案一:缓存默认值

在数据库查询不存在时,可以将其缓存为默认值。不过设置的时间不宜过长(建议设置为60s),如果过了一会儿数据库新增了该数据,时间太长的话,就会出现数据不一致的情况。

方案二:业务逻辑前置判断

如果有人为的恶意攻击,用不合理的参数去请求系统,按照方案一新增了大量的不存在的key到内存中,极端情况下,缓存也被撑爆了……

所以我们可以在接口处进行数据合法性校验,进行提前拒绝。比如:a接口只允许查询18+的成年人的数据,请求带有未成年人就明显不合适。

方案三:使用布隆过滤器

如果有人很巧妙的用合理的参数但是系统内不存在的key请求系统,系统按照方案一、方案二也会新增大量的不存在key到内存中,这时又怎么办呢……

那我们可以使用布隆过滤器(本文不做扩展哈,请自行了解),当把数据写入数据库的时候,使用布隆过滤器进行标记,当有请求时,如果发现缓存消失,在去查询数据库前,先查询布隆过滤器该key是否存在,如果不存在,直接返回,不过布隆过滤器有一定的误判率,这个可以忽略。

方案四:加互斥锁或队列

经过方案一、二、三的优化,应该可以处理穿透的问题吧,但是仔细想一想,兄弟儿,我们是高并发的场景啊,所以,场景是大量的请求同一时刻都来请求同一个key,发现没有这个key,全都去访问数据库,以至于系统崩溃……

在这里,我们要加一个锁,只保证一个线程去创建缓存,其余的等待,这样就ok了。

缓存击穿

缓存击穿(Cache Breakdown)指的是一个热点key,在不停的被大量的请求访问,当这个热点key缓存失效的瞬间,大量的请求访问到数据库,以至于系统崩溃。

Redis:缓存穿透、缓存击穿、缓存雪崩?

方案一:永不过期

提前把热点数据不设置过期时间,后台异步更新缓存。

但是!我又要说但是了!我现在举个例子,就要推翻这个方案了,打自己的脸。

我们自家的甲秀宝商城最近3月8日女神节做一次大促,把运营童鞋收集整理的关于女性热点商品都做了永不过期,但是大促当天发现面巾纸是卖的最多的,差点就要祭天了……

所以,真实场景是就像你根本无法知道女朋友想什么一样,同理你也不能真正的预估到客户想买什么,哪个是热点商品,所以,这个方案也就是面试吹吹……

方案二:加互斥锁或队列

其实我理解缓存击穿和缓存穿透差不多,所以加一个互斥锁,让一个线程正常请求数据库,其他线程等待即可(这里可以使用线程池来处理),都创建完缓存,让其他线程请求缓存即可。

缓存雪崩

缓存雪崩(Cache Avalanche)指的是当某一个时刻出现大规模的缓存失效,然后大量的请求直接访问到数据库,以至于压垮数据库,造成系统崩溃等情况。

Redis:缓存穿透、缓存击穿、缓存雪崩?

出现这种情况的可能有两种:

  • 缓存采用相同的过期时间。
  • 缓存服务出现故障。

方案一:相对随机数过期时间

key的过期时间加上一个随机值,保证不是同一时间失效,即可。

方案二:分布式集群部署

单节点缓存服务容易宕机,那我们就部署个集群,然后把缓存均匀的分不到不同的服务器上,搞定。

方案三:服务限流、熔断、降级

当流量到一定的阈值或者服务出现异常、故障时,直接返回“请稍后再试”的友好性处理,让一部分用户正常使用,其他用户多重试几次,不过这样难免会降低用户体验,不过几个人有问题也总比整个系统崩溃好~

END

缓存穿透、缓存击穿、缓存雪崩,说白了核心就是“避免无效(或重复)的请求”到数据库,所以我觉得只要是以这个思想去设计都是ok的~

Redis:缓存穿透、缓存击穿、缓存雪崩?

好了,本文到此结束,带大家了解了《Redis:缓存穿透、缓存击穿、缓存雪崩?》,希望本文对你有所帮助!关注golang学习网公众号,给大家分享更多数据库知识!

声明:本文转载于:51cto 如有侵犯,请联系study_golang@163.com删除
相关阅读
更多>
最新阅读
更多>
课程推荐
更多>
评论列表