快看，我们的分布式缓存就是这样把注册中心搞崩的！

末蓝、 2024-04-17 05:29 52阅读 0赞

公众号后台回复“**学习**”，获取作者独家秘制精品资料

![640?wx\_fmt=png][640_wx_fmt_png]

![640?wx\_fmt=jpeg][640_wx_fmt_jpeg]

扫描下方海报二维码，试听课程：

**（课程详细大纲，请参见文末）**

![640?wx\_fmt=jpeg][640_wx_fmt_jpeg 1]

![640?wx\_fmt=png][640_wx_fmt_png]

文章转自公众号：吃草的罗汉

写公众号两年以来，每当有机会写故障类主题的时候，我都会在开始前静静地望着显示器很久，经过多次煎熬和挣扎之后才敢提起笔来

为什么呢？因为这样的话题很容易招来吐槽，比如 “说了半天，不就是配置没配好吗？”，或者 “这代码是猪写的吗？你们团队有懂性能测试的同学吗？”

这样的评论略带挑衅，而且充满了鄙视之意。

不过我觉得，在技术的世界里，多数情况都是客观场景决定了主观结果，而主观结果又反映了客观场景

能够把场景与结果串起来，用自己的方式写下来，传播出去，与有相同经历的同学聊上一聊，也未尝不是一件好事。

上个月，我们的系统因注册中心崩塌而引发的一场事故，本是一件稀松平常的事件，可我们猜中了开始却没料到原因，始作俑者竟是已在产线运行多年的某分布式缓存系统。

**这到底是怎么一回事呢？**

**先来回顾一下故障过程**

11月，某交易日的上午10点左右。

在中间件监控系统没有触发任何报警的情况下，某应用团队负责人突然跑过来说：“怎么缓存响应怎么慢？你们在干什么事吗？”

由于此正在交易盘中，中间件运维团队瞬间炸锅，紧急查看了一系列监控数据

先是通过Zabbix查看了如CPU、内存、网络及磁盘等基础预警，一切正常，再查看服务健康状况，经过一圈折腾之后，也没发现任何疑点。

懵圈了，没道理啊。

10点30分，收到一通报警信息，内容为 “ZK集群中的某一个节点故障，端口不通，不能获取node信息，请迅速处理！”

这简单，ZK服务端口不通，重启，立即恢复。

10点40分，ZK集群全部瘫痪，无法获取Node数据，由于应用系统的Dubbo服务与分布式缓存使用的是同一套ZK集群，而且在此期间应用未重启过，因此应用服务自身暂时未受到影响。

没道理啊，无论应用侧还是缓存侧，近一个月以来都没有发布过版本，而且分布式缓存除了在ZK中存一些节点相关信息之外，基本对ZK无依赖。

10点50分，ZK集群全部重启，10分钟后，再次瘫痪。

神奇了，到底哪里出了问题呢？

**10点55分，ZK集群全部重启，1分钟后，发现Node Count达到近22W+，再次崩溃。**

![640?wx\_fmt=png][640_wx_fmt_png 1]

10点58分，通过增加监控脚本，查明Node源头来自分布式缓存系统的本地缓存服务

**11点00分，通过控制台关闭本地缓存服务后，ZK集群第三次重启，通过脚本删除本地化缓存所产生的大量node信息。**

11点05分，产线ZK集群全部恢复，无异常。

一场风波虽说过去了，但每个人的脸上流露出茫然的表情，邪了门了，这本地缓存为什么能把注册中心搞崩塌？都上线一年多了，之前为什么不出问题？为什么偏偏今天出事？

一堆的问好，充斥着每个人的大脑。

**我们本地缓存的工作机制**

去年，我曾经在 [\#好买的分布式缓存中间件\#][Link 1] 的内容中对我们的分布式缓存做过相对详细的说明，所以在这里，我就通过系统流程示意图的方式，简要的说明下我们本地缓存系统的一些核心工作机制。

**| 非本地缓存的工作机制**

![640?wx\_fmt=png][640_wx_fmt_png 2]

**| ****本地缓存的工作机制 - KEY预加载/更新**

![640?wx\_fmt=png][640_wx_fmt_png 3]

**| 本地缓存的工作机制 - Set/Delete操作**

![640?wx\_fmt=png][640_wx_fmt_png 4]

**| 本地缓存的工作机制 - Get操作**

![640?wx\_fmt=png][640_wx_fmt_png 5]

顺带提一句，**由于历史性与资源紧缺的原因，我们部分缓存系统与应用系统的ZK集群是混用的，**正因如此，给本次事故埋下了隐患。

**ZK集群是怎样被搞挂的呢？**

说到这里，相信对中间件有一定了解的人基本能猜出本事件的全貌。

**简单来说，就是在上线初期，由于流量小，应用系统接入量小，我们本地缓存的消息通知是利用ZK来实现的，而且还用到了广播。**

**但随着流量的增加与应用系统接入量的增多，消息发送量成倍增长，最终达到承载能力的上限，ZK集群崩溃。**

的确，原因基本猜对了，但消息发送量为什么会成倍的增长呢？

根据本地缓存的工作机制，我们一般会在里面存些什么呢？

1.  更新频率较低，但访问却很频繁，比如系统参数或业务参数。
2.  单个Key/Value较大，网络消耗比较大，性能下降明显。
3.  服务端资源匮乏或不稳定（如I/O），但对稳定性要求极高。

懵圈了，就放些参数类信息，而且更新频率极低，这样就把五个节点的ZK集群发爆了？

为了找到真相，我们立即进行了代码走读，最终发现了蹊跷。

![640?wx\_fmt=png][640_wx_fmt_png 6]

根据设计，在 “本地缓存的工作机制 - Set/Delete操作” 的工作机制中，当一个Key完成服务端缓存操作后，如果没有被加到本地缓存规则列表中的KEY，是不可能被触发消息通知的

但这里明显存在BUG，导致把所有的KEY都发到了ZK中。

这样就很好理解了，虽然应用系统近期没有发布版本，但却通过缓存控制台，悄悄地把分布式锁加到了这套缓存分片中

所以交易一开盘，只需几十分钟，立马打爆。

另外，除了发现BUG之外，通过事后测试验证，我们还得出了以下几点结论：

1.  利用ZK进行消息同步，ZK本身的负载能力较弱，是否切换到MQ？
2.  监控手段的单一，监控的薄弱；
3.  系统部署结构不合理，基础架构的ZK不应该与应用的ZK混用；

![640?wx\_fmt=png][640_wx_fmt_png 7]

说到这里，这个故事也该结束了。

**讲在最后**

看完这个故事，一些爱好怼人的小伙伴也许会忍不住发问。你们自己设计的架构，你们自己编写的代码，难道不知道其中的逻辑吗？这么低级的错误，居然还有脸拿出来说？

那可未必，对每个技术团队而言，核心成员的离职与业务形态的变化，都或多或少会引发技术团队对现有系统形成 “知其然而，却不知其所以然” 的情况，虽说每个团队都在想方设法进行避免，但想完全杜绝，绝非易事。

作为技术管理者，具备良好的心态，把每次故障都看成是一次蝉变的过程，从中得到总结与经验，并加以传承，今后不再就犯，那就是好样的。

不过，万一哪天失手，给系统来了个彻底瘫痪，该怎么办呢？

祝大家一切顺利吧。

**END**

**如有收获，请划至底部，点击“在看”，谢谢！**

![640?wx\_fmt=png][640_wx_fmt_png]

《21天互联网Java进阶面试训练营（分布式篇）》详细目录，**扫描图片末尾的二维码，试听课程**

![640?wx\_fmt=jpeg][640_wx_fmt_jpeg 2]

![640?wx\_fmt=jpeg][640_wx_fmt_jpeg 3]

![640?wx\_fmt=jpeg][640_wx_fmt_jpeg 4]

![640?wx\_fmt=png][640_wx_fmt_png]

欢迎长按下图关注公众号**石杉的架构笔记**

![640?wx\_fmt=jpeg][640_wx_fmt_jpeg 5]

**BAT架构经验倾囊相授**

[640_wx_fmt_png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/11/9720b007cd1745b78220fb1961619053.png
[640_wx_fmt_jpeg]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/11/b027601c60244d17a929f8f05abeafd2.png
[640_wx_fmt_jpeg 1]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/11/2209c689eeaf44e88a55d28b4d05f685.png
[640_wx_fmt_png 1]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/11/14d5098b0d3546478b0bfc7631d246d2.png
[Link 1]: https://mp.weixin.qq.com/s?__biz=MzIzODQ3NDQ4Mw==&mid=2247483808&idx=1&sn=da69e9c92e2488f4d0893c18fddeaeb1&scene=21#wechat_redirect
[640_wx_fmt_png 2]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/11/08560a47b37b4e64818fa67189609bab.png
[640_wx_fmt_png 3]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/11/c6fc3debeb6c40de906f56ba17579173.png
[640_wx_fmt_png 4]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/11/12cbf61b57da4f78b1a6dc699cb48d66.png
[640_wx_fmt_png 5]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/11/5ef7c032657e4c359445207f92ff125a.png
[640_wx_fmt_png 6]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/11/4546f29fec354b71a435a60cfc9681c8.png
[640_wx_fmt_png 7]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/11/295222ba4ce7408aad16b560f1741945.png
[640_wx_fmt_jpeg 2]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/11/a29b491940bd4df188a5e07eb9fd439b.png
[640_wx_fmt_jpeg 3]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/11/945c64184b144035ad455d856ff412f5.png
[640_wx_fmt_jpeg 4]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/11/be44aeac20c0476098e3287441f74b2f.png
[640_wx_fmt_jpeg 5]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/11/f5f09dc7c6c84b4a8a2ed88434a46ce0.png