Redis某个节点突然挂了，整个系统竟然崩溃得这么惨，真是没想到后果这么严重

（引用来源：某电商平台技术团队事后复盘报告摘要）

“那天下午，我们正在准备一场大型促销活动的预热，系统流量已经开始缓慢爬坡，一切都显得按部就班，监控大屏上的各项指标虽然比平时活跃，但都在绿色安全范围内，突然，运维同事喊了一声：‘不好，缓存集群报警！’我们心里咯噔一下，赶紧看向屏幕，只见代表其中一个Redis节点的图标变成了刺眼的红色，按照我们之前的理解，Redis集群不是有高可用机制吗？一个节点挂了，其他节点应该能顶上来啊，最多就是瞬间有个小抖动，性能稍微下降一点罢了，所以一开始，虽然紧张，但并没觉得是天塌下来的大事。

（引用来源：同一复盘报告中对故障链的描述）

没想到,真正的噩梦才刚刚开始，首先崩溃的不是缓存层，而是依赖缓存最深的商品详情页服务，因为这个节点恰好承载了当天预热最火爆的几个爆款商品的缓存数据，节点一挂，这些服务瞬间失去了绝大部分缓存数据，像被抽掉了主心骨，只能疯狂地直接去查询后端的数据库，数据库平时在缓存的保护下，悠闲自得，突然之间，海量的查询请求像海啸一样扑了过来，数据库的连接池在几秒钟内就被耗尽，这导致了第一个严重后果：所有需要查询数据库的服务，不仅仅是商品详情页，包括用户信息、库存查询、优惠券校验等等，全部因为获取不到数据库连接而开始超时、报错，用户端的表现就是页面加载极其缓慢，最后变成白屏或者错误提示。

（引用来源：开发人员A在内部技术论坛的讨论帖）

这还没完,更让我们没想到的连锁反应发生了，由于我们的系统在设计时，为了防止缓存穿透，对于一些热点key，使用了分布式锁来保证只有一个线程去数据库查询并回写缓存，当那个Redis节点挂掉的时候，正好有一批请求在等待这个锁，而锁的过期时间是依赖Redis的，节点失效，这些锁的状态变得不确定，导致的结果是，一部分服务实例认为锁还存在，一直在傻等，最终线程被占满，服务本身也失去了响应能力；而另一部分服务实例可能认为锁已经超时释放了，于是又涌向本已不堪重负的数据库去查询数据，形成了恶性循环，这种因为一个缓存节点宕机而引发的‘锁失效’和‘线程池耗尽’的并发症，是我们事先完全没有预料到的，它像一种病毒，从一个点快速扩散到了整个应用层。

（引用来源：系统架构师在复盘会议上的发言）

也是最致命的一击,来自于系统的‘雪崩’效应，当应用层的大量服务实例因为上述原因变得不可用或响应极慢时，它们上游的网关、负载均衡器也开始承受巨大压力，因为下游服务不‘吃’请求了，请求堆积在网关层面，很快就耗尽了网关的资源，整个系统的入口被堵死，外部用户看到的就是全站无法访问，从第一个Redis节点变红，到全站服务几乎不可用，整个过程可能都不到五分钟，我们之前做的很多容灾演练，更多是考虑数据库主从切换、机房断网这种大场景，却万万没想到，一个被我们认为具备‘高可用’能力的缓存集群，仅仅因为其中一个节点意外宕机，就能通过如此复杂的连锁反应，把整个庞大的系统拖入深渊。

（引用来源：运维负责人总结的教训文档）

事后我们反思,这次惨痛的教训根源在于几个‘没想到’：第一，过分相信了中间件集群的‘自愈’能力，没有为单点故障设置足够快和有效的自动切换与隔离方案，第二，对缓存失效后，数据库的真实抗压能力评估过于乐观，没有设置严格的降级策略和限流措施，第三，也是最重要的，系统各个组件之间的依赖关系比我们想象的要紧密和脆弱，一个看似非核心的组件出问题，竟然能通过层层传递，放大成全局性灾难，我们原以为系统是‘钢筋混凝土’结构，坏了一根钢筋还有别的撑着，实际上它更像一副多米诺骨牌，推倒关键的一张，后面就全倒了，这次崩溃，真的给我们上了血淋淋的一课。”