摘要：優(yōu)志愿張海鵬宋體背景宋體每年月下旬到月下旬期間是高考填志愿的高峰期，也是優(yōu)志愿后端面臨大流量高并發(fā)請求的業(yè)務(wù)高峰期。對于優(yōu)志愿讀多寫少的場景及其業(yè)務(wù)高峰期，用戶可以按需增刪節(jié)點，更好地實現(xiàn)讀取性能的擴展。

隨著用戶規(guī)模的增長，數(shù)據(jù)庫的壓力也在成倍增加。面對大流量、高并發(fā)，UCloud MongoDB 做到了高效，并展現(xiàn)出了更好的性能體驗。

—— 優(yōu)志愿 CTO 張海鵬

背景

每年 6 月下旬到 8 月下旬期間是高考填志愿的高峰期，也是優(yōu)志愿后端面臨大流量高并發(fā)請求的業(yè)務(wù)高峰期。優(yōu)志愿 APP 旨在為 3000 萬高中生提供專業(yè)的自主招生、志愿填報、留學(xué)、游學(xué)等升學(xué)規(guī)劃服務(wù)，通過四年技術(shù)的不斷創(chuàng)新和研發(fā)，憑借 “省控線差值法” 等專利級核心算法，目前已累計服務(wù) 400 多萬考生，實現(xiàn)錄取成功率高達 99.2%，最大浪費分僅 6 分的成績。而要為如此多考生提供服務(wù)，面對上億條檢索依然穩(wěn)定，并不是簡單的事。

面臨的痛點

優(yōu)志愿原先基于物理機自建的 MSSQL（Microsoft SQL Sever）數(shù)據(jù)庫，面對大流量高并發(fā)的業(yè)務(wù)高峰，暴露了以下問題：

1. 跟不上業(yè)務(wù)彈性擴容的節(jié)奏

自建 MSSQL 在做讀寫分離、AlwaysOn 配置、給每臺 windows 客戶端配置域名帳戶等操作時十分繁瑣，且隨著業(yè)務(wù)流量的增長需要不定時的增加服務(wù)器及應(yīng)用配置，從硬件采購、機器部署到應(yīng)用配置整個周期也較長。

2. 性能遭遇瓶頸，DBA 耗時耗力

另外，由于優(yōu)志愿的業(yè)務(wù)場景主要是以查詢、索引操作為主，讀寫比例大概 7:3，之前自建的 MSSQL 在數(shù)據(jù)達到千萬條時檢索速度大幅下降，需要及時更新索引目錄，不僅影響考生的用戶體驗，且耗費大量的 DBA 人力成本。

經(jīng)過一番調(diào)研對比后，優(yōu)志愿選擇了使用 UCloud MongoDB 產(chǎn)品來解決以上問題。

為什么選擇 UCloud MongoDB？

UCloud MongoDB 是基于成熟云計算技術(shù)的高可用、高性能的數(shù)據(jù)庫服務(wù)，無縫兼容開源的 MongoDB 版本；除了底層采用高可用主從架構(gòu)外，還提供滿足數(shù)據(jù)分片場景的配置節(jié)點和路由節(jié)點功能；同時提供災(zāi)備、備份、監(jiān)控等全套解決方案。

（圖：在 UCloud 控制臺 UDB 產(chǎn)品界面可選擇創(chuàng)建 MongoDB 實例）

●一鍵創(chuàng)建副本集實現(xiàn)讀寫分離

UCloud MongoDB 默認構(gòu)建三節(jié)點的副本集：Primary 節(jié)點 + 一個 Secondary 節(jié)點 + 一個 Arbiter 節(jié)點構(gòu)成。通過副本集中創(chuàng)建節(jié)點操作可支持擴展更多節(jié)點的副本集（例如：五節(jié)點、七節(jié)點或者更多個節(jié)點）。對于優(yōu)志愿讀多寫少的場景及其業(yè)務(wù)高峰期，用戶可以按需增刪 Secondary 節(jié)點，更好地實現(xiàn)讀取性能的擴展。利用 UCloud MongoDB 副本集讀寫分離解決了大部分讀取的請求，即使數(shù)據(jù)到達上億條時檢索速度依然很快。副本集架構(gòu)如圖所示：

●靈活高可用集群架構(gòu)

為了解決隨著數(shù)據(jù)量增多而導(dǎo)致的性能瓶頸，MongoDB 還支持分片集群，即多個分片可以組成一個集群對外提供服務(wù)。分片集群（MongoDB3.4 及以上版本），由 Config Server 三副本 + N 個 Mongos +N 個 shard 數(shù)據(jù)分片構(gòu)成，MongoDB 集群設(shè)置好分片規(guī)則，通過 mongos 操作數(shù)據(jù)庫就能自動把對應(yīng)的數(shù)據(jù)操作請求轉(zhuǎn)發(fā)到對應(yīng)的分片機器上。MongoDB 采用 “分片” 能夠快速搭建一個高可用可擴展的的分布式集群，具有大數(shù)據(jù)量、高擴展性、高性能、靈活數(shù)據(jù)模型、高可用性等特性。分片集群架構(gòu)如圖：

●彈性擴縮容更省成本

用戶依據(jù)業(yè)務(wù)實際流量可以彈性擴展 MongoDB 資源，滿足不同業(yè)務(wù)階段數(shù)據(jù)庫性能和存儲空間的需求。在業(yè)務(wù)高峰期可即時開通所需數(shù)據(jù)庫資源，無需在業(yè)務(wù)初期采購高成本硬件，從而有效減少硬件成本投入。在業(yè)務(wù)低峰期可隨時刪除釋放，避免數(shù)據(jù)庫資源的閑置浪費。正如優(yōu)志愿 CTO 張海鵬所說：“使用 UCloud MongoDB 數(shù)據(jù)庫后，運維成本節(jié)省了 80%，硬件采購成本減少 55%。”

查詢索引優(yōu)化，打破性能瓶頸

卡頓現(xiàn)象

在今年高考前夕，優(yōu)志愿新版業(yè)務(wù)上線后業(yè)務(wù)出現(xiàn)小高峰的第一天，用戶反饋他們的 APP 登陸界面非常卡頓，經(jīng)運維排查發(fā)現(xiàn)瓶頸出現(xiàn)在數(shù)據(jù)庫層，并邀請了 UCloud 云數(shù)據(jù)庫團隊介入解決相關(guān)性能問題。

團隊首先查看了一些常見的會引起 MongoDB 出現(xiàn)卡頓的性能指標(biāo)，發(fā)現(xiàn)大多數(shù)指標(biāo)正常。隨著排查深入進行，發(fā)現(xiàn)實例全局寫鎖的加鎖比例異常高。如下圖所示。

圖中加鎖百分比達到 100%，意味著所有全局寫操作全部卡住，大量的請求在排隊等待加鎖，性能急劇下降。

語句優(yōu)化

UCloud 云數(shù)據(jù)庫團隊針對當(dāng)時用戶所有慢查詢的總體情況，以及相關(guān)慢查詢的查詢計劃，并結(jié)合用戶的索引情況進行了詳細分析。經(jīng)過分析后，團隊首先發(fā)現(xiàn)用戶的相關(guān)表當(dāng)中一些索引可以優(yōu)化，從而提升查詢的效率，因此為用戶添加了相關(guān)的索引。在添加了索引之后，團隊結(jié)合監(jiān)控指標(biāo)，發(fā)現(xiàn)情況有所改善，但是依舊沒有從根本上解決問題。

然后，團隊仔細分析了用戶耗時最長的典型查詢語句，并模擬執(zhí)行查看執(zhí)行計劃。在執(zhí)行過程中，團隊發(fā)現(xiàn)雖然相關(guān)集合已經(jīng)加上了索引，但是用戶的查詢語句的執(zhí)行計劃中并沒有使用最優(yōu)的索引。進一步分析后，團隊發(fā)現(xiàn)用戶的最慢的語句基本都是 aggregate 操作，結(jié)合加鎖異常的性能指標(biāo)，團隊仔細查看了用戶的具體 aggregate 的語句內(nèi)容。最后發(fā)現(xiàn)耗時長的這些 aggregate 操作當(dāng)中沒有用到分組功能 ($group)。這樣的話其實也可以通過 MongoDB 最普通的 find 操作來達到同樣的效果。例如原語句：

db.this_collection.aggregate([ {$match: { UserId: 12345}}, {$match: { $or: [{FieldA: 1}, {FieldB: 2}]}}, {$sort: {_id: -1}}, {$skip: 0}, {$limit: 1}])

這條語句做的事情，其實是在 this_collection 這個集合中，查找 UserId = 12345 并且 還滿足 FieldA = 1 或者 FieldB = 2 的文檔記錄。查找到記錄之后，對所有結(jié)果的_id 進行倒序排列，并且拿出第一條結(jié)果。團隊用下面的 find 語句達到同樣的效果。改造后語句：

db.this_collection.find( { UserId: 12345, {$or: [{FieldA: 1}, {FieldB: 2}]} }).sort({_id: -1}).skip(0).limit(1)

MongoDB 的 find () 進行了更加高程度的查詢優(yōu)化，并且使用 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})

團隊嘗試改造其中的一條典型耗時語句，并且在模擬環(huán)境中執(zhí)行并查看改造后的執(zhí)行計劃。結(jié)果驚喜地發(fā)現(xiàn)，即使在沒有使用 hint 操作的情況下，find () 操作已經(jīng)能夠使用我們認為的最優(yōu)索引了，經(jīng)過改造后的查詢性能有了大幅的提升。

當(dāng)天晚上，UCloud 云數(shù)據(jù)庫團隊立即幫助用戶改造了他們最慢的查詢中所有可以被改造的查詢語句，并且把改造建議同步給用戶。用戶的研發(fā)當(dāng)晚收到改造建議后，緊急修改代碼并發(fā)布。

瓶頸解除

發(fā)布后的第二天，用戶通過監(jiān)控界面，可以看到慢查詢顯著減少，并且加鎖隊列顯著降低，數(shù)據(jù)庫的負載也明顯降低，整個系統(tǒng)能更高效的提供服務(wù)，改造后的監(jiān)控圖如下：

可以看到，在改造之后，全局寫鎖的加鎖等待百分比大大減少，慢查詢也大大減少。改造取得了非常好的效果，用戶的 APP 后期再也沒有出現(xiàn)過 DB 層面的性能瓶頸。

Prometheus 全方位實時監(jiān)控及告警

為了幫助用戶提供更實時的大盤監(jiān)控，UCloud 在后臺搭建了一套 Prometheus 監(jiān)控系統(tǒng)，將所有數(shù)據(jù)庫實例的關(guān)鍵性能指標(biāo)全列出來，相比普通的監(jiān)控平臺，借助 Prometheus 可以更清晰的看到所有數(shù)據(jù)庫實例當(dāng)前的情況，掌握數(shù)據(jù)庫當(dāng)前的狀態(tài)，也可以更好的發(fā)現(xiàn)數(shù)據(jù)庫的運行趨勢。

例如連接數(shù)情況：

對于每一個實例，提供更詳細的監(jiān)控。例如 WTcache 的狀態(tài)：

加鎖的狀態(tài)：

監(jiān)控系統(tǒng)和告警系統(tǒng)相結(jié)合，可以在大于閥值時，直接告警出來，有利于問題的提前發(fā)現(xiàn)。借助 UCloud 搭建的 Prometheus ，用戶無需自行搭建監(jiān)控系統(tǒng)，也無需關(guān)心底層數(shù)據(jù)存儲、數(shù)據(jù)展示、系統(tǒng)運維等問題。

寫在最后

UCloud 云數(shù)據(jù)庫 UDB 自 2013 年正式商用后，一直緊跟開源社區(qū)的步伐，目前已經(jīng)廣泛支持業(yè)內(nèi)主流的數(shù)據(jù)庫類型，除了 MongoDB, 還支持例如 MySQL、PostgreSQL 以及 SQLServer。在開源的基礎(chǔ)上，UCloud 數(shù)據(jù)庫團隊還自研了分布式架構(gòu)、讀寫分離、存儲計算分離等特性。同時，為了更貼近用戶的使用場景，UCloud 數(shù)據(jù)庫團隊近期將推出 Cloud DBA 新產(chǎn)品，在控制臺提供 Prometheus 監(jiān)控入口、界面管理巡檢和 SQL 分析等功能，以更加智能的方式提高 DBA 運維效率。