高考填志愿的上亿流量高峰，看 MongoDB 如何应对

随着用户规模的增加，数据库的压力也在成倍增长。面对大流量、高并发，UCloud MongoDB 作到了高效，并展示出了更好的性能体验。

—— 优志愿 CTO 张海鹏

背景

每一年 6 月下旬到 8 月下旬期间是高考填志愿的高峰期，也是优志愿后端面临大流量高并发请求的业务高峰期。优志愿 APP 旨在为 3000 万高中生提供专业的自主招生、志愿填报、留学、游学等升学规划服务，经过四年技术的不断创新和研发，凭借 “省控线差值法” 等专利级核心算法，目前已累计服务 400 多万考生，实现录取成功率高达 99.2%，最大浪费分仅 6 分的成绩。而要为如此多考生提供服务，面对上亿条检索依然稳定，并非简单的事。

面临的痛点

优志愿原先基于物理机自建的 MSSQL（Microsoft SQL Sever）数据库，面对大流量高并发的业务高峰，暴露了如下问题：

1. 跟不上业务弹性扩容的节奏

自建 MSSQL 在作读写分离、AlwaysOn 配置、给每台 windows 客户端配置域名账户等操做时十分繁琐，且随着业务流量的增加须要不定时的增长服务器及应用配置，从硬件采购、机器部署到应用配置整个周期也较长。

2. 性能遭遇瓶颈，DBA 耗时耗力

另外，因为优志愿的业务场景主要是以查询、索引操做为主，读写比例大概 7:3，以前自建的 MSSQL 在数据达到千万条时检索速度大幅降低，须要及时更新索引目录，不只影响考生的用户体验，且耗费大量的 DBA 人力成本。

通过一番调研对比后，优志愿选择了使用 UCloud MongoDB 产品来解决以上问题。

为何选择 UCloud MongoDB？

UCloud MongoDB 是基于成熟云计算技术的高可用、高性能的数据库服务，无缝兼容开源的 MongoDB 版本；除了底层采用高可用主从架构外，还提供知足数据分片场景的配置节点和路由节点功能；同时提供灾备、备份、监控等全套解决方案。

（图：在 UCloud 控制台 UDB 产品界面可选择建立 MongoDB 实例）

●一键建立副本集实现读写分离

UCloud MongoDB 默认构建三节点的副本集：Primary 节点 + 一个 Secondary 节点 + 一个 Arbiter 节点构成。经过副本集中建立节点操做可支持扩展更多节点的副本集（例如：五节点、七节点或者更多个节点）。对于优志愿读多写少的场景及其业务高峰期，用户能够按需增删 Secondary 节点，更好地实现读取性能的扩展。利用 UCloud MongoDB 副本集读写分离解决了大部分读取的请求，即便数据到达上亿条时检索速度依然很快。副本集架构如图所示：

 ●灵活高可用集群架构

为了解决随着数据量增多而致使的性能瓶颈，MongoDB 还支持分片集群，即多个分片能够组成一个集群对外提供服务。分片集群（MongoDB3.4 及以上版本），由 Config Server 三副本 + N 个 Mongos +N 个 shard 数据分片构成，MongoDB 集群设置好分片规则，经过 mongos 操做数据库就能自动把对应的数据操做请求转发到对应的分片机器上。MongoDB 采用 “分片” 可以快速搭建一个高可用可扩展的的分布式集群，具备大数据量、高扩展性、高性能、灵活数据模型、高可用性等特性。分片集群架构如图：

●弹性扩缩容更省成本

用户依据业务实际流量能够弹性扩展 MongoDB 资源，知足不一样业务阶段数据库性能和存储空间的需求。在业务高峰期可即时开通所需数据库资源，无需在业务初期采购高成本硬件，从而有效减小硬件成本投入。在业务低峰期可随时删除释放，避免数据库资源的闲置浪费。正如优志愿 CTO 张海鹏所说：“使用 UCloud MongoDB 数据库后，运维成本节省了 80%，硬件采购成本减小 55%。”

查询索引优化，打破性能瓶颈

卡顿现象

在今年高考前夕，优志愿新版业务上线后业务出现小高峰的第一天，用户反馈他们的 APP 登录界面很是卡顿，经运维排查发现瓶颈出如今数据库层，并邀请了 UCloud 云数据库团队介入解决相关性能问题。

团队首先查看了一些常见的会引发 MongoDB 出现卡顿的性能指标，发现大多数指标正常。随着排查深刻进行，发现实例全局写锁的加锁比例异常高。以下图所示。

图中加锁百分比达到 100%，意味着全部全局写操做所有卡住，大量的请求在排队等待加锁，性能急剧降低。

语句优化

UCloud 云数据库团队针对当时用户全部慢查询的整体状况，以及相关慢查询的查询计划，并结合用户的索引状况进行了详细分析。通过分析后，团队首先发现用户的相关表当中一些索引能够优化，从而提高查询的效率，所以为用户添加了相关的索引。在添加了索引以后，团队结合监控指标，发现状况有所改善，可是依旧没有从根本上解决问题。

而后，团队仔细分析了用户耗时最长的典型查询语句，并模拟执行查看执行计划。在执行过程当中，团队发现虽然相关集合已经加上了索引，可是用户的查询语句的执行计划中并无使用最优的索引。进一步分析后，团队发现用户的最慢的语句基本都是 aggregate 操做，结合加锁异常的性能指标，团队仔细查看了用户的具体 aggregate 的语句内容。最后发现耗时长的这些 aggregate 操做当中没有用到分组功能 ($group)。这样的话其实也能够经过 MongoDB 最普通的 find 操做来达到一样的效果。例如原语句：

db.this_collection.aggregate([ {match: { sort: {_id: -1}}, {limit: 1}]) 这条语句作的事情，实际上是在 this_collection 这个集合中，查找 UserId = 12345 而且 还知足 FieldA = 1 或者 FieldB = 2 的文档记录。查找到记录以后，对全部结果的_id 进行倒序排列，而且拿出第一条结果。团队用下面的 find 语句达到一样的效果。改造后语句：

db.this_collection.find( { UserId: 12345, {$or: [{FieldA: 1}, {FieldB: 2}]} }).sort({_id: -1}).skip(0).limit(1) MongoDB 的 find () 进行了更加高程度的查询优化，而且使用 find () 操做还有一个额外的好处，就是用户能够在 find () 最后接上 hint () 操做，能够强制指定使用的索引，使查询性能大幅提高。好比上面的例子中，若是在 this_collection 这个集合中，对 UserId 有索引，咱们能够直接强制查询使用这个索引。具体语句能够变成：

db.this_collection.find( { UserId: 12345, {$or: [{FieldA: 1}, {FieldB: 2}]} }).sort({_id: -1}).skip(0).limit(1).hint({UserId: 1}) 团队尝试改造其中的一条典型耗时语句，而且在模拟环境中执行并查看改造后的执行计划。结果惊喜地发现，即便在没有使用 hint 操做的状况下，find () 操做已经可以使用咱们认为的最优索引了，通过改造后的查询性能有了大幅的提高。

当天晚上，UCloud 云数据库团队当即帮助用户改造了他们最慢的查询中全部能够被改造的查询语句，而且把改造建议同步给用户。用户的研发当晚收到改造建议后，紧急修改代码并发布。

瓶颈解除

发布后的次日，用户经过监控界面，能够看到慢查询显著减小，而且加锁队列显著下降，数据库的负载也明显下降，整个系统能更高效的提供服务，改造后的监控图以下：

 能够看到，在改造以后，全局写锁的加锁等待百分比大大减小，慢查询也大大减小。改造取得了很是好的效果，用户的 APP 后期再也没有出现过 DB 层面的性能瓶颈。

Prometheus 全方位实时监控及告警

为了帮助用户提供更实时的大盘监控，UCloud 在后台搭建了一套 Prometheus 监控系统，将全部数据库实例的关键性能指标全列出来，相比普通的监控平台，借助 Prometheus 能够更清晰的看到全部数据库实例当前的状况，掌握数据库当前的状态，也能够更好的发现数据库的运行趋势。

例如链接数状况：

对于每个实例，提供更详细的监控。例如 WTcache 的状态：

加锁的状态：

监控系统和告警系统相结合，能够在大于阀值时，直接告警出来，有利于问题的提早发现。借助 UCloud 搭建的 Prometheus ，用户无需自行搭建监控系统，也无需关心底层数据存储、数据展现、系统运维等问题。

写在最后

UCloud 云数据库 UDB 自 2013 年正式商用后，一直紧跟开源社区的步伐，目前已经普遍支持业内主流的数据库类型，除了 MongoDB, 还支持例如 MySQL、PostgreSQL 以及 SQLServer。在开源的基础上，UCloud 数据库团队还自研了分布式架构、读写分离、存储计算分离等特性。同时，为了更贴近用户的使用场景，UCloud 数据库团队近期将推出 Cloud DBA 新产品，在控制台提供 Prometheus 监控入口、界面管理巡检和 SQL 分析等功能，以更加智能的方式提升 DBA 运维效率。