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

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

为什么要使用缓存

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

缓存的好处有以下两点:

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

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

缓存穿透

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

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

方案一:缓存默认值

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

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

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

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

方案三:使用布隆过滤器

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

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

方案四:加互斥锁或队列

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

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

缓存击穿

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

方案一:永不过期

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

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

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

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

方案二:加互斥锁或队列

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

缓存雪崩

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

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

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

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

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

方案二:分布式集群部署

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

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

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

END

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


责任编辑:武晓燕 来源: 今日头条
相关推荐

2019-10-12 14:19:05

Redis数据库缓存

2020-03-16 14:57:24

Redis面试雪崩

2021-06-05 09:01:01

Redis缓存雪崩缓存穿透

2022-03-08 00:07:51

缓存雪崩数据库

2019-11-05 14:24:31

缓存雪崩框架

2023-04-14 07:34:19

2022-05-27 07:57:20

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

2023-12-06 13:38:00

Redis缓存穿透缓存击穿

2023-11-10 14:58:03

2022-11-18 14:34:28

2024-04-18 11:43:28

缓存数据库Redis

2024-03-12 10:44:42

2024-04-07 00:00:02

Redis雪崩缓存

2021-12-25 22:28:27

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

2020-10-13 07:44:40

缓存雪崩 穿透

2022-07-11 07:36:36

缓存缓存雪崩缓存击穿

2020-10-23 10:46:03

缓存雪崩击穿

2020-12-28 12:37:36

缓存击穿穿透

2020-03-05 09:09:18

缓存原因方案

2023-01-31 08:37:11

缓存穿透击穿
点赞
收藏

51CTO技术栈公众号