如果线上 Redis 挂了。然后所有请求打到数据库导致数据库也挂了。
这是啥？
Redis 挂了，不就是缓存都没了吗？
缓存都没了，不就是缓存雪崩了吗？
缓存雪崩了，不就导致数据库挂了吗？
一提到“缓存雪崩”这四个字，缓存穿透、缓存击穿这几兄弟，是不是就立马条件反射的出现在你的脑海里面了，还顺带着对应的几套解决方案。
然后就像背书似的，什么缓存全没了，什么缓存没有数据库中有，什么缓存和数据库中都没有…
张口就是几分钟不带停顿的。
另外关于缓存击穿和缓存穿透，很多同学都会搞混。
你换一个记法，缓存戳穿、缓存戳透。
穿，只是穿过了缓存。
透，是直接干到底。
你细品，应该就不会记混。
除了上面的“Redis 缓存三连击”这一套八股文之外，还隐藏着另外一个八股文：
Redis 挂了，为什么挂了？怎么就挂了？是不是有单点问题？
这不就是问你 Redis 服务的高可用吗？
说到 Redis 的高可用，脑子里面必须马上蹦出来主从、哨兵和集群吧？
想到这些了，张口又是几分钟不带停顿的。
但是这几分钟的千言万语，马上就被下面这个问题给干懵逼了？
这时该怎么进行恢复？
现在问你怎么恢复，就是事中的事儿了。
你得先说怎么恢复，再说怎么预防。
你要是上来就回答前面说的什么“缓存三连击”、“高可用架构”，还包括大多数同学能想到的多级缓存、限流措施、服务降级、熔断机制，这些都有点牵强。
因为毕竟这些手段都是事前的预防措施，上来就说这些背书痕迹比较明显。
答肯定是要答的，从事中恢复过度到事前预防方案，而且重点就是事前预防，那么我们怎么过度的自然一点呢？
先说事中怎么恢复，其实我觉得几句话就说完了。
服务挂了啊，老哥，还能怎么恢复，当然是重启服务啊。
站在运维人员的角度，当然优先考虑是先把 Redis 和数据库服务重新启动起来啦。
但是启动之前得先做个小操作，把流量摘掉，可以先把流量拦截在入口的地方，比如简单粗暴的通过 Nginx 的配置把请求都转到一个精心设计的错误页面，就是说这么一个意思。
这样做的目的是为了防止流量过大，直接把新启动的服务，启动一个打挂一个的情况出现。
要是启动起来又扛不住了，请在心里默念分布式系统三大利器：
不行就加钱，堆机器嘛。
要觉得堆机器没啥技术含量，你就再从缓存预热的角度答一个。
就是当 Redis 服务重新启动后&#x
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容，请联系我们，一经查实，本站将立刻删除。
如需转载请保留出处：https://51itzy.com/kjqy/26225.html