殃及池鱼!Redis挂了的情况下流量把数据库也打挂了,怎么办?

当Redis服务发生故障导致缓存雪崩,进而使数据库不堪重负时,如何应对?本文分析了缓存击穿、穿透、雪崩的区别,探讨了Redis高可用架构,并提出事中恢复和事前预防的策略,包括重启服务、流量拦截、预热缓存等,强调了服务无状态、多级缓存、限流和熔断的重要性。
摘要由CSDN通过智能技术生成

是这样的,前几天有个读者给我发消息,说面试的时候遇到一个场景题:

他说他当时,一时间竟然找不到回答问题的角度,感觉自己没有回答到点子上。

我仔细想了一下,确实是感到这个问题有一丝丝的奇怪,有一种让人千言万语,又突然懵逼不知从何说起的神奇力量。

为什么这么说呢?

我们先读题啊,仔细的读一遍题,我给你翻译一下。

如果线上 Redis 挂了。然后所有请求打到数据库导致数据库也挂了。

这是啥?

Redis 挂了,不就是缓存都没了吗?

缓存都没了,不就是缓存雪崩了吗?

缓存雪崩了,不就导致数据库挂了吗?

一提到“缓存雪崩”这四个字,缓存穿透、缓存击穿这几兄弟,是不是就立马条件反射的出现在你的脑海里面了,还顺带着对应的几套解决方案。

然后就像背书似的,什么缓存全没了,什么缓存没有数据库中有,什么缓存和数据库中都没有...

张口就是几分钟不带停顿的。

另外关于缓存击穿和缓存穿透,很多同学都会搞混。

你换一个记法,缓存戳穿、缓存戳透。

穿,只是穿过了缓存。

透,是直接干到底。

你细品,应该就不会记混。

除了上面的“Redis 缓存三连击”这一套八股文之外,还隐藏着另外一个八股文:

Redis 挂了,为什么挂了?怎么就挂了?是不是有单点问题?

这不就是问你 Redis 服务的高可用吗?

说到 Redis 的高可用,脑子里面必须马上蹦出来主从、哨兵和集群吧?

想到这些了,张口又是几分钟不带停顿的。

但是这几分钟的千言万语,马上就被下面这个问题给干懵逼了?

这时该怎么进行恢复?

现在问你怎么恢复,就是事中的事儿了。

你得先说怎么恢复,再说怎么预防。

你要是上来就回答前面说的什么“缓存三连击”、“高可用架构”,还包括大多数同学能想到的多级缓存、限流措施、服务降级、熔断机制,这些都有点牵强。

因为毕竟这些手段都是事前的预防措施,上来就说这些背书痕迹比较明显。

答肯定是要答的,从事中恢复过度到事前预防方案,而且重点就是事前预防,那么我们怎么过度的自然一点呢?

先说事中怎么恢复,其实我觉得几句话就说完了。

服务挂了啊,老哥,还能怎么恢复,当然是重启服务啊。

站在运维人员的角度,当然优先考虑是先把 Redis 和数据库服务重新启动起来啦。

但是启动之前得先做个小操作,把流量摘掉,可以先把流量拦截在入口的地方,比如简单粗暴的通过 Nginx 的配置把请求都转到一个精心设计的错误页面,就是说这么一个意思。

这样做的目的是为了防止流量过大,直接把新启动的服务,启动一个打挂一个的情况出现。

要是启动起来又扛不住了,请在心里默念分布式系统三大利器:

不行就加钱,堆机器嘛。

要觉得堆机器没啥技术含量,你就再从缓存预热的角度答一个。

就是当 Redis 服务重新启动后,通过程序先放点已知的热点 ke

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值