什么!分布式缓存搞崩了注册中心

教育要闻 阅读(1247)

Focus on high-quality technology in the Java field, welcome to follow

From: Java Sunflower Collection

eb25817d0ac24ed48e2c4604076672eb

Whenever I have the opportunity to write a faulty topic, I will look at the monitor quietly for a long time before I start. After many times of suffering and struggle, I dare to bring up the pen. Why? Because such a topic is easy to invite, such as "saying for a long time, isn't the configuration not equipped?", or "Is this code written by the pig? Do your team have students who understand performance testing?", such a comment Slightly provocative, and full of contempt.

However, I think that in the world of technology, most of the cases are objective scenes that determine subjective results, while subjective results reflect objective scenes, stringing scenes and results, writing them down in their own way, spreading them out, and having the same It’s not a good thing that a classmate who has gone through a chat.

Last month, an accident caused by the collapse of the registration center in our system was a common incident. But we guessed that we didn’t expect the reason at the beginning. The initiator was actually a person who had been running on the production line for many years. Distributed caching system.

What the hell is this all about?

In November, around 10 am on a trading day.

In the case where the middleware monitoring system did not trigger any alarms, an application team leader suddenly ran over and said, "How slow is the cache response? What are you doing?"

As this is in the trading disk, the middleware operation and maintenance team instantly froze, and urgently checked a series of monitoring data. First, through Zabbix, the basic warnings such as CPU, memory, network and disk were checked. Everything is normal, and then the service health status is checked. After a tossing in a circle, no doubts were found.

It’s a circle, it’s unreasonable.

xx10:30,收到告警消息,内容为“ZK集群中的节点故障,端口不可达,无法获取节点信息。请快速处理!”。

这很简单,ZK服务端口无法访问,重新启动并立即恢复。

在10:40,ZK集群完全被遮挡,无法获得节点数据。由于应用程序系统的Dubbo服务和分布式缓存使用相同的ZK集群集,并且在此期间应用程序尚未重新启动,因此应用程序服务本身暂时不受影响。

它没有意义,无论是在应用程序端还是在缓存端,它都没有在过去一个月发布,并且除了在ZK中存储一些节点相关信息之外,分布式缓存不依赖于ZK。

在10:50,ZK集群重新启动。 10分钟后,又一次。

这太棒了,出了什么问题?

在10:55,ZK集群完全重启。 1分钟后,发现节点计数达到近22W +并再次坠毁。

db53e88e4b8748bc9ec49d01e1e1b438

在10:58,通过添加监视脚本,发现Node源来自分布式缓存系统的本地缓存服务。

在11:00,通过控制台关闭本地缓存服务后,ZK集群第三次重启,脚本删除本地缓存生成的大量节点信息。

11:05,生产线的ZK集群全部恢复,没有异常。

虽然暴风雨已经过去,但每个人的脸上都露出了一个空白的表情,邪恶的门已经消失了。为什么这个本地缓存会崩溃注册中心?我已经上线超过一年了。为什么我之前没有问题?你今天为什么发生意外?

一堆你好,充满了每个人的大脑。

在这里,我通过系统流程图的原理图简要介绍我们本地缓存系统的一些核心工作机制。

|非本地缓存工作机制

d2125f5229de4c12b5411f6951587ab7

|本地缓存的工作原理 - KEY预加载/更新

65d5d43de67146cfb85a0607b25eeb58

|本地缓存工作机制 - 设置/删除操作

6ea80d1cee474f7ea35c98074713d339

|本地缓存工作机制 - 获取操作

349a470ffc60479cb52780846b24ba0b

顺便说一句,由于历史和资源短缺,我们的一些缓存系统和应用系统ZK集群是混合的,这就是为什么这埋藏了隐患。

说到这一点,我相信对中间件有一定了解的人基本上可以猜出这件事的全貌。

简而言之,在发布的早期,由于流量小和应用程序访问量少,我们使用ZK实现本地缓存的消息通知,并且还使用广播。但是,随着流量的增加和应用系统的访问量的增加,消息传输量呈指数增长,最终达到承载容量的上限,ZK群集崩溃。

实际上,原因基本上是正确的,但为什么发送的消息数量呈指数级增长?

根据本地缓存的工作机制,我们通常会在其中存储什么?

更新频率较低,但访问非常频繁,例如系统参数或业务参数。单个密钥/值很大,网络消耗相对较大,性能显着下降。服务器资源稀缺或不稳定(例如I/O),但稳定性要求非常高。

圆圈结束后,输入一些参数信息,更新频率非常低,以便五节点ZK群集爆炸?

为了找到真相,我们立即进行了代码阅读,终于找到了答案。

5ff2f19d3091496b82db5a600635de95

根据设计,在“本地缓存工作机制 - 设置/删除操作”的工作机制中,当密钥完成服务器端缓存操作时,如果KEY未添加到本地缓存规则,则无法触发名单。注意到,但这里有一个明确的BUG,导致所有KEY被发送到ZK。

这很容易理解,虽然应用程序系统最近还没有发布一个版本,但是通过缓存控制台,悄然将分布式锁定添加到缓存段,因此事务打开,只需几十分钟,立即爆发。

此外,除了发现BUG之外,通过测试后验证,我们还得出以下结论:

ZK用于消息同步。 ZK本身的负载能力很弱。它切换到MQ吗?监测手段单一,监测薄弱;系统部署结构不合理,基础设施ZK不应与应用程序ZK混合;60b1a01246994e67bc63122c59e99a48

话虽如此,这个故事应该结束了。

读完这个故事后,一些爱好爱好的朋友可能无法提问。你知道你自己设计的架构的逻辑吗,你自己编写的代码?这样一个低级别的错误,实际上还有面子出来?

情况可能并非如此。对于每个技术团队而言,核心成员的离职和业务形式的变化将或多或少地触发技术团队形成对现有系统的“了解但不知道”,尽管每个团队都试图避免它,但它要完全消除它并不容易。

作为一名技术经理,他态度良好,认为每次失败都是一种变态过程。从结论,经验和继承来看,它将来不会发生,这很好。

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

49e16cc73b2a40438f39fc8c4481c030

XX