搞会这个索引添加法，十亿级时延敏感集群想抖动都难( 二 )

该业务当前数据比较小， 10亿级别，但是随着时间增长后续可能会增加到百亿级别，考虑到以后可能存在分片扩容的需求，因此采用了分片模式。
该集群当前写入更新比较少，后续可能存在大量写入更新的场景，大量写入更新需要多分片来支撑。
我司在mongos代理增加了很多功能，例如限流、流量控制、权限细化控制、监控信息完善等功能，因此默认采用分片模式。

三、问题快速发现及解决
3.1 问题发现
某天，突然告警中心打来电话，突然收到如下告警信息：

本文插图
几乎四个从节点先后收到同样的告警，节点时延部分请求超过20ms ，由于该业务是非常核心的影响业务营收的核心集群，非常紧张。但是，有一个很奇怪的现象，主节点访问时延正常，只有从节点时延抖动。
此外，还不停收到实例不可用异常告警，对应监控曲线如下：

本文插图

本文插图
说明：上图曲线一根代表客户端当前已用连接数，一根曲线代表剩余可用连接数。
3.2 问题排查过程
收到告警后，发现业务有很多慢日志(时延敏感业务，慢日志打印阀值为20ms) ，同时慢日志都走了最优索引。

通过mongo shell登陆对应节点后台

于是通过mongo shell登陆节点后台，但是登陆不上，出现如下打印：
1.MongoDB shell version v3.6.13
2.connecting to: mongodb://x.x.x.x:20001/test?gssapiServiceName=mongodb
3.2021-04-29T11:09:15.049+0800 E QUERY [thread1] Error: network error while attempting to run command 'isMaster' on host x.x.x.x:20001' :
4.connect@src/mongo/shell/mongo.js:263:13
5.@(connect):1:6
6.exception: connect failed
由于节点登陆不上，因此登陆到存储节点查看后台日志，日志中有大量的打印提示连接数耗光了，如下图：

本文插图

节点系统监控统计分析

从上面的现象可以看出链接耗光了，于是分析节点所在服务器系统监控，发现一个问题，磁盘IO非常高，如下：

本文插图

分析mongod实例日志

由于从节点登陆不上，系统磁盘IO很高，因此怀疑有慢操作在运行，于是分析实例日志，发现如下现象：