Redis挂了，流量把数据库也打挂了，怎么办？

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

这是啥？

Redis 挂了，不就是缓存都没了吗？

缓存都没了，不就是缓存雪崩了吗？

缓存雪崩了，不就导致数据库挂了吗？

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

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

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

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

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

穿，只是穿过了缓存。

透，是直接干到底。

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

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

Redis 挂了，为什么挂了？怎么就挂了？是不是有单点问题？

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

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

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

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

这时该怎么进行恢复？

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

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

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

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

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

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

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

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

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

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

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

不行就加钱，堆机器嘛。

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

就是当 Redis 服务重新启动后&#x