Mongodb特定场景性能数十倍提升优化实践(记一次mongodb核心集群雪崩故障)

1. 问题背景
   某核心JAVA长连接服务使用mongodb作为主要存储，客户端数百台机器连接同一mongodb集群，短期内出现多次性能抖动问题，此外，还出现一次“雪崩”故障，同时流量瞬间跌零，无法自动恢复。本文分析这两次故障的根本原因，包括客户端配置使用不合理、mongodb内核链接认证不合理、代理配置不全等一系列问题，最终经过多方努力确定问题根源。
   该集群有十来个业务接口访问，每个接口部署在数十台业务服务器上面，访问该mongodb机器的客户端总数超过数百台，部分请求一次拉取数十行甚至百余行数据。
   该集群为2机房同城多活集群(选举节不消耗太多资源，异地的第三机房来部署选举节点)，架构图如下：
   
   从上图可以看出，为了实现多活，在每个机房都部署有对应代理，对应机房客户端链接对应机房的mongos代理，每个机房多个代理。代理层部署IP:PORT地址列表(注意：不是真实IP地址)如下：
   A机房代理地址列表：1.1.1.1:111,2.2.2.2:1111,3.3.3.3:1111
   B机房代理地址列表：4.4.4.4:1111,4.4.4.4:2222
   A机房三个代理部署在三台不同物理机，B机房2个代理部署在同一台物理机。此外，A机房和B机房为同城机房，跨机房访问时延可以忽略。

   集群存储层和config server都采用同样的架构：A机房(1主节点+1从节点) + B机房(2从节点)+C机房(1个选举节点arbiter)，即2(数据节点)+2(数据节点)+1(选举节点)模式。
   该机房多活架构可以保证任一机房挂了，对另一机房的业务无影响，具体机房多活原理如下：
   

1.如果A机房挂掉，由于代理是无状态节点，A机房挂掉不会影响B机房的代理。
2.如果A机房挂掉，同时主节点在A机房，这时候B机房的2个数据节点和C机房的选举节点一共三个节点，可以保证新选举需要大于一半以上节点这个条件，于是B机房的数据节点会在短时间内选举出一个新的主节点，这样整个存储层访问不受任何影响。

   本文重点分析如下6个疑问点：

1.为什么突发流量业务会抖动？
2.为什么数据节点没有任何慢日志，但是代理负载缺100%？
3.为何mongos代理引起数小时的“雪崩”，并且长时间不可恢复？
4.为何一个机房代理抖动，对应机房业务切到另一个机房后，还是抖动？
5.为何异常时候抓包分析，客户端频繁建链断链，并且同一个链接建链到断链间隔很短？
6.理论上代理就是七层转发，消耗资源更少，相比mongod存储应该更快，为何mongod存储节点无任何抖动，mongos代理缺有抖动？

2. 故障过程
   2.1 业务偶尔流量高峰，业务抖动？
   该集群一段时间内有多次短暂的抖动，当A机房客户端抖动后，发现A机房对应代理负载很高，于是切换A机房访问B机房代理，但是切换后B机房代理同样抖动，也就是多活切换没有作用，具体过程分析如下。
   2.1.1 存储节点慢日志分析
   首先，分析该集群所有mongod存储节点系统CPU、MEM、IO、load等监控信息，发现一切正常，于是分析每个mongod节点慢日志(由于该集群对时延敏感，因此慢日志调整为30ms)，分析结果如下：
   
   
   
   从上图可以看出，存储节点在业务抖动的时候没有任何慢日志，因此可以判断存储节点一切正常，业务抖动和mongod存储节点无关。
   2.1.2 Mongos代理分析
   存储节点没有任何问题，因此开始排查mongos代理节点。由于历史原因，该集群部署在其他平台，该平台对QPS、时延等监控不是很全，造成早期抖动的时候监控没有及时发现。抖动后，迁移该平台集群到oppo自研的新管控平台，新平台有详细的监控信息，迁移后QPS监控曲线如下：
   
   每个流量徒增时间点，对应业务监控都有一波超时或者抖动，如下：
   
   分析对应代理mongos日志，发现如下现象：抖动时间点mongos.log日志有大量的建链接和断链接的过程，如下图所示：
   
   从上图可以看出，一秒钟内有几千个链接建立，同时有几千个链接断开，此外抓包发现很多链接短期内即断开链接，现象如下(断链时间-建链时间=51ms, 部分100多ms断开)：