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

作者介绍
杨亚洲，前滴滴出行专家工程师，现任OPPO文档数据库mongodb负责人，负责数万亿级数据量文档数据库mongodb内核研发、性能优化及运维工作，一直专注于分布式缓存、高性能服务端、数据库、中间件等相关研发。
线上某mongodb集群存储影响公司收入流水的核心数据，本文分享该集群为何多个索引串行后台会引起集群抖动，并且部分节点出现了连接数耗光等问题。同时通过本案例，给出时延敏感业务该最优方式添加索引，做到对业务最小化影响或者无影响。
索引对业务查询性能提升起着至关重要的作用，但是绝大部分mongodb程序员和DBA对时延敏感业务的索引添加方法是错误的。
本文主要完成一下几个目的：

为何background后台加索引会引起时延敏感集群抖动？
为何前面两个索引添加过程没触发告警，第三个索引添加完成后才触发告警？
为何只有从节点抖动，主节点时延一切正常？
为何连接数暴涨？
连接数耗光， mongo shell无法登陆查看节点内部状态信息，如何破局？
时延敏感型业务如何做到业务无感知索引添加？

一、业务背景
某业务存储公司核心数据，集群异常会影响公司流水收入，该业务对时延非常敏感，稍有抖动就容易引起客户端超时异常，该业务场景如下：

数据量很小， 10亿级
核心业务
时延敏感
分片模式，单个分片
读写分离
读多写少
峰值流量8-10W/s

该集群对应mongodb内核版本：3.6.13 ，某天业务自己通过mongodb管控平台串行方式添加几个索引(background后台添加) ，一个索引添加执行完成返回后，业务开始下一个索引的添加。
添加第一个索引和第二个索引完成后，业务没告警，但是当业务添加完第三个索引后，开始收到部分查询时延超过阀值告警。
二、集群架构
2.1 集群部署架构
该集群部署架构如下：

本文插图
该业务集群对应流量监控曲线如下：

本文插图
如上图所示，该业务部署只有一个分片，该分片为一主四从结构5节点。分片1采用5节点的原因如下：

核心业务， 5副本方式部署，可以容忍两个节点估值
时延敏感，由于业务优先读从节点，因此可以通过增加分片从节点的方式提升业务的QPS 。

2.2 一个分片为何要选择分片模式？复制集不是可以满足要求吗？
从上面的结构图可以看出，该集群只有一个分片，采用了分片模式架构，为何不选择复制集架构，这样还可以省掉mongos代理和config server的成本开销。采用分片模式主要基于如下因素考虑：