连环触发！MongoDB核心集群雪崩故障背后竟是……( 三 ) 作者介绍杨亚洲

通知业务把所有客户端超时时间提高到500ms 。

但是，心里始终有很多疑惑和悬念，主要在以下几个点：

存储节点4个，代理节点5个，存储节点无任何抖动，反而七层转发的代理负载高？
为何抓包发现很多新连接几十ms或者一百多ms后就断开连接了？频繁建链断链？
为何代理QPS只有几万，这时代理CPU消耗就非常高，而且全是sy%系统负载？以我多年中间件代理研发经验，代理消耗的资源很少才对，而且CPU只会消耗us% ，而不是sy%消耗。

2、同一个业务几天后“雪崩”了
好景不长，业务下掉突发流量的接口没过几天，更严重的故障出现了，机房B的业务流量在某一时刻直接跌0了，不是简单的抖动问题，而是业务直接流量跌0 ，系统sy%负载100% ，业务几乎100%超时重连。
1）机器系统监控分析
机器CPU和系统负载监控如下：

文章插图
从上图可以看出，几乎和前面的突发流量引起的系统负载过高现象一致，业务CPU sy%负载100% ， load很高。登陆机器获取top信息，现象和监控一致。

文章插图
同一时刻对应网络监控如下：

文章插图
磁盘IO监控如下：

文章插图

文章插图
从上面的系统监控分析可以看出，出问题的时间段，系统CPU sy%、load负载都很高，网络读写流量几乎跌0 ，磁盘IO一切正常，可以看出整个过程几乎和之前突发流量引起的抖动问题完全一致。
2）业务如何恢复
第一次突发流量引起的抖动问题后，我们扩容所有的代理到8个，同时通知业务把所有业务接口配置上所有代理。由于业务接口众多，最终B机房的业务没有配置全部代理，只配置了原先的两个处于同一台物理机的代理(4.4.4.4:1111,4.4.4.4:2222) ，最终触发MongoDB的一个性能瓶颈(详见后面分析) ，引起了整个MongoDB集群”雪崩”
最终，业务通过重启服务，同时把B机房的8个代理同时配置上，问题得以解决。
3） mongos代理实例监控分析
分析该时间段代理日志，可以看出和上述第一点同样的现象，大量的新键连接，同时新连接在几十ms、一百多ms后又关闭连接。整个现象和之前分析一致，这里不在统计分析对应日志。
此外，分析当时的代理QPS监控，正常query读请求的QPS访问曲线如下，故障时间段QPS几乎跌零雪崩了：

文章插图
Command统计监控曲线如下：

文章插图
从上面的统计可以看出，当该代理节点的流量故障时间点有一波尖刺，同时该时间点的command统计瞬间飙涨到22000(实际可能更高，因为我们监控采样周期30s,这里只是平均值) ，也就是瞬间有2.2万个连接瞬间进来了。 Command统计实际上是db.ismaster统计，客户端connect服务端成功后的第一个报文就是ismaster报文，服务端执行db.ismaster后应答客户端，客户端收到后开始正式的sasl认证流程。
正常客户端访问流程如下：