某百亿级mongodb业务只保存近期7天的数据，由于数据量大、流量高，数据过期删除点比较集中，同时不能错峰方式解决问题，因此如何利用最小物理成本来满足业务需求就成为了本集群性能优化的难点。

通过几轮和业务配合调优，包括存储引擎调优、数据删除方式调优、业务错峰读写等，最终完美解决了业务痛点，达到ms级业务读写访问。

线上某业务数据量约100亿，白天为写流量高峰期，峰值写约14W/s，如下图所示：

业务每天白天生产数据，同时凌晨批量拉取过去几天数据做大数据分析，整个集群只保存最近七天数据。

单条数据约800字节，如下所示：

通过和业务对接梳理，该集群规模及业务需求总结如下：

分片数及存储节点套餐规格选定评估过程如下：

此外，由于分片集群还有mongos代理和config server复制集，因此还需要评估mongos代理和config server节点规格。由于config server只主要存储路由相关元数据，因此对磁盘、CUP、MEM消耗都很低；mongos代理只做路由转发只消耗CPU，因此对内存和磁盘消耗都不高。最终，为了最大化节省成本，我们决定让一个代理和一个config server复用同一个容器，容器规格如下：

8CPU/8G内存/50G磁盘，一个代理和一个config server节点复用同一个容器。

分片及存储节点规格总结：4分片/16CPU、64G内存、1T磁盘。

mongos及config server规格总结：8CPU/8G内存/50G磁盘

该业务数据不是很重要，为了节省成本，因此我们采用2+1模式部署，也就是：2mongod+1arbiter模式，同城机房部署，部署架构图如下图所示：

考虑到数据重要性不高，通过2mongod+1arbiter模式即可满足用户要求，同时可以最大化节省成本。

该集群优化过程按照如下两个步骤优化：业务使用集群前的性能优化、业务使用过程中的性能优化。

业务提前建好查询对应的最优索引，同时创建过期索引：

db.dailyCloudOperateInfo.createIndex( { "createTime": 1 }, { expireAfterSeconds: 604800} )

和业务沟通确定，业务每条数据都携带有一个设备标识userId，同时业务查询更新等都是根据userId维度查询该设备下面的单条或者一批数据，因此片建选择userId。

sh.shardCollection("cloud_track.dailyCloudOperateInfo", {userId:"hashed"}, false, { numInitialChunks: 8192} )

1）第一轮优化：存储引擎优化

业务高峰期主要是数据写入和更新，内存脏数据较多，当脏数据比例达到一定比例后用户读写请求对应线程将会阻塞，用户线程也会去淘汰内存中的脏数据page，最终写性能下降明显。

wiredtiger存储引擎cache淘汰策略相关的几个配置如下:

由于业务全量迁移数据是持续性的大流量写，而不是突发性的大流量写，因此eviction_target、eviction_trigger、eviction_dirty_target、eviction_dirty_trigger几个配置用处不大，这几个参数阀值只是在短时间突发流量情况下调整才有用。

但是，在持续性长时间大流量写的情况下，我们可以通过提高wiredtiger存储引擎后台线程数来解决脏数据比例过高引起的用户请求阻塞问题，淘汰脏数据的任务最终交由evict模块后台线程来完成。

全量大流量持续性写存储引擎优化如下：

db.adminCommand( { setParameter : 1, "wiredTigerEngineRuntimeConfig" : "eviction=(threads_min=4, threads_max=20)"})

2）第一轮优化后存在的问题

经过存储引擎后台线程数的调优后，数据写入和更新瓶颈解决，写入和更新过程时延都很平滑。但是随着一周后开始数据过期，业务写开始大量抖动，如下所示：

从上图可以看出平均时延极端情况下甚至达到了几百ms，这是业务完全接受不了的。通过mongostat监控发现如下现象：

上图为mongodb单机模块架构图，主节点默认启用一个TTLMonitor线程，借助查询引起模块实时扫描过期索引，然后把满足条件的数据删除。整个删除过程没有走command命令处理模块，而命令计数操作只会在command模块计数，因此主节点的过期删除不会有delete操作。

命令处理模块处理流程及其计数统计详见：

mongodb内核源码模块化设计与实现专栏

更多mongodb模块化源码设计实现详见：

https://github.com/y123456yz/reading-and-annotate-mongodb-3.6

从前面的分析可以看出，我们三个分片支撑不了持续性20W/S的更新和删除操作，因此我们考虑业务改造使用方式，把过期删除确定到凌晨低峰期。

但是业务上线后出现其他的问题，由于业务凌晨会持续性的批量拉取分析过去几天的数据，如果过期和批量读数据叠加到一起，严重影响业务查询效率。最终，该方案不可行，如果不扩容，则需要其他方案。

为了不增加成本，同时3个分片又支撑不了20W/s的读写删除等导致，为了尽量通过3个分片不扩容条件下来满足用户需求，因此转变方式，通过删表的方式来避免过期，具体实现如下：

    该方案业务时延统计对应收益如下：

如上图所示，通过过期方式的优化，最终问题彻底解决，并且读写时延控制在0.5ms-2ms。

通过前面的一系列优化，最终没有扩容，并且解决了业务过期和大量数据写入更新引起的时延抖动问题，总体收益如下：