本文來自獲得《2021MongoDB技術實踐與應用案例徵集活動》入圍案例獎作品

作者：vivo網際網路技術

1.業務背景

隨著公司業務發展和使用者規模的增多，很多專案都在打造自己的評論功能，而評論的業務形態基本類似。當時各專案都是各自設計實現，存在較多重複的工作量；並且不同業務之間資料存在孤島，很難產生聯絡。因此我們決定打造一款公司級的評論業務中臺，為各業務方提供評論業務的快速接入能力。在經過對各大主流app評論業務的競品分析，我們發現大部分評論的業務形態都具備評論、回覆、二次回覆、點贊等功能。具體如下圖所示：

涉及到的核心業務概念有：

【主題 topic】評論的主題，商城的商品、應用商店的app、社群的帖子。

【評論 comment】使用者針對於主題發表的內容。

【回覆 reply】使用者針對於某條評論發表的內容，包括一級回覆和二級回覆。

2.為什麼選擇MongoDB

團隊在資料庫選型設計時，對比了多種主流的資料庫，最終在MySQL和MongoDB兩種儲存之進行抉擇。

由於評論業務的特殊性，它需要如下能力:

【欄位擴充套件】業務方不同評論模型儲存的欄位有一定差異，需要支援動態的自動擴充套件。

【海量資料】作為公司中臺服務，資料量隨著業務方的增多成倍增長，需要具備快速便捷的水平擴充套件和遷移能力。

【高可用】作為中颱產品，需要提供快速和穩定的讀寫能力，能夠讀寫分離和自動恢復

而評論業務不涉及使用者資產，對事務的要求性不高。因此我們選用了MongoDB叢集作為了最底層的資料儲存方式。

3.MongoDB在評論中臺的應用

3.1 MongoDB叢集知識

叢集架構

由於單臺機器存在磁碟/IO/CPU等各方面的瓶頸，所以MongoDB提供叢集方式的部署架構，如圖所示：

主要由以下三個部分組成：

mongos ：路由伺服器，負責管理應用端的具體連結。應用端請求到mongos服務後，mongos把具體的讀寫請求轉發應的shard節點上執行。一個叢集可以有1~N個mongos節點。

config ：配置伺服器，用於分儲存分片集合的後設資料和配置資訊，必須為複製集( 關於複製集概念戳我 ) 方式部署。mongos通過config配置伺服器合的後設資料資訊。

shard： 用於儲存集合的分片資料的MongoDB服務，同樣必須以複製集方式部署。

片鍵

MongoDB資料是存在collection(對應MySQL表)中。叢集模式下，collection按照片鍵（shard key）拆分成多個區間，每個區間組成一個chunk，按照規則分佈在不同的shard中。並形成後設資料註冊到config服務中管理。

分片鍵只能在分片集合建立時指定，指定後不能修改。

分片鍵主要有兩大型別：

hash分片：通過hash演算法進行雜湊，資料分佈的更加平均和分散。支援單列和多列hash。
範圍分片：按照指定片鍵的值分佈，連續的key往往分佈在連續的區間，更加適用範圍查詢場景。單資料雜湊性由分片鍵本身保證。

3.2 評論中臺的實踐

片鍵的選擇

MongoDB叢集中，一個集合的資料部署是分散在多個shard分片和chunk中的，而我們希望一個評論列表的查詢最好只訪問到一個shard分片，因此確定了範圍分片的方式。

起初設定只使用單個key作為分片鍵，以comment評論表舉例，主要欄位有{"_id":唯一id,"topicId":主題id,"text":文字內容,"createDate":時間} ,考慮到一個主題id的評論儘可能連續分佈，我們設定的分片鍵為topicId。隨著效能測試的介入，我們發現了有兩個非常致命的問題：

jumbo chunk問題
唯一鍵問題

jumbo chunk：

官方文件中，MongoDB中的chunk大小被限制在了1M-1024M。分片鍵的值是chunk劃分的唯一依據，在資料量持續寫入超過chunk size設定值時， MongoDB叢集就會自動的進行分裂或遷移。而對於同一個片鍵的寫入是屬於一個chunk，無法被分裂，就會造成 jumbo chunk 問題。

舉例：若我們設定1024M為一個chunk的大小，單個document 5KB計算，那麼單個chunk能夠儲存21W左右document。考慮熱點的主題評論( 如微信評論)，評論數可能達到40W+，因此單個chunk很容易超過1024M。超過最大size的chunk依然能夠提供讀寫服務，只是不會再進行分裂和遷移，長久以往會造成叢集之間資料的不平衡。

唯一鍵問題：

MongoDB叢集的唯一鍵設定增加了限制，必須是包含分片鍵的；如果_id不是分片鍵，_id索引只能保證單個shard上的唯一性。

You cannot specify a unique constraint on a hashed index
For a to-be-sharded collection, you cannot shard the collection if the collection has other unique indexes
For an already-sharded collection, you cannot create unique indexes on other fields

因此我們刪除了資料和集合，調整topicId 和 _id 為聯合分片鍵重新建立了集合。這樣即打破了chunk size的限制，也解決了唯一性問題。

遷移和擴容

隨著資料的寫入，當單個chunk中資料大小超過指定大小時(或chunk中的檔案數量超過指定值)。MongoDB叢集會在插入或更新時，自動觸發chunk的拆分。

拆分會導致集合中的資料塊分佈不均勻，在這種情況下，MongoDB balancer元件會觸發叢集之間的資料塊遷移。balancer元件是一個管理資料遷移的後臺程式，如果各個shard分片之間的chunk數差異超過閾值，balancer會進行自動的資料遷移。

balancer是可以線上對資料遷移的，但是遷移的過程中對於叢集的負載會有較大影響。一般建議可以通過如下設定，在業務低峰時進行。

db.settings.update({ _id: "balancer" },{ $set: { activeWindow : { start : "<start-time>", stop : "<stop-time>" } } },{ upsert: true })

MongoDB的擴容也非常簡單，只需要準備好新的shard複製集後，在mongos節點中執行：

sh.addShard("<replica_set>/<hostname><:port>")

擴容期間因為chunk的遷移，同樣會導致叢集可用性降低，因此只能在業務低峰進行。

叢集的擴充套件

作為中颱服務，對於不同的接入業務方，通過表隔離來區分資料。以comment評論表舉例，每個接入業務方都單獨建立一張表，業務方A表為 comment_clientA ，業務方B表為 comment_clientB，均在接入時建立表和相應索引資訊。但只是這樣設計存在幾個問題：

單個叢集，不能滿足部分業務資料物理隔離的需要
叢集調優(如split遷移時間)很難業務特性差異化設定
水平擴容帶來的單個業務方資料過於分散問題

因此我們擴充套件了MongoDB的叢集架構：

擴充套件後的評論MongoDB叢集增加了【邏輯叢集】和【物理叢集】的概念。一個業務方屬於一個邏輯叢集，一個物理叢集包含多個邏輯叢集。
增加了路由層設計，由應用負責擴充套件spring的MongoTemplate和連線池管理，實現了業務到MongoDB叢集之間的切換選擇服務。
不同的MongoDB分片叢集，實現了物理隔離和差異調優的可能。

3.3 自研MongoDB事件採集處理平臺及應用

評論中臺中有很多統計資料的查詢：評論數、回覆數、點贊數、未讀回覆數等等，由於評論資料量較大，單個業務的資料量都在億級別以上，瀏覽器、短視訊等內容型的業務評論資料量都是在百億級別，前臺業務查詢時對資料庫做實時count效能肯定是無法達到要求的，因此我們選擇使用空間換時間的方式，在資料表中增加相關的統計資料欄位，每次有新的評論發表或者狀態變更時對該欄位的值做$inc原子操作。這種方式確實能夠提升資料查詢的效率，在評論這種讀多寫少的場景下十分合適。

帶來的問題 ：

作為中颱類專案，需要適配vivo不同的評論業務場景，隨著業務發展，這部分統計口徑和型別也會隨之變動，各種統計型別越來越多（目前已有20多種統計），在程式碼主流程中耦合的統計邏輯越來越越重，並且各種統計邏輯的程式碼散落在系統程式碼的各個角落，系統也越來越臃腫，並且程式碼變更時很容易帶來統計資料不準的問題，這類問題會影響評論及回覆的下拉展示的效果，舉一個較為典型的例子，如果當前評論下有1條回覆，但是統計錯誤，誤認為沒有回覆，則當前人回覆資訊則無法顯示，如果需要修復此類問題，我們發現涉及面比較廣，無法收斂。因此我們對統計相關的邏輯進行了一次大的重構。

事件資料服務

我們選擇事件驅動的方式將統計邏輯從主流程中解構出來，每一個統計都有其對應的變更事件，例如：

評論發表事件 > 評論數統計點贊、
取消點贊事件 > 點贊數統計
僅自身可見事件 > 使用者僅自身可見數統計

但是這個事件如何發出來呢？一開始我們想的是在主流程中根據場景傳送不同型別的事件，但是這種方式不夠靈活，每次增加一種統計型別就需要增加一種事件型別。轉換下思路，其實每發出一種事件其本質上是資料庫某些資料發生了變化，那我們為何不監聽資料庫的操作日誌，採集資料的變更，通過對比變更前後的資料來自定義事件，進而進行資料的統計，整體流程如下：

其中監聽模組負責監聽MongoDB資料變更，並對變更事件進行處理和分發，當被監聽的表發生資料變更時會將變更前後的資料通過mq的方式分發給資料服務。資料服務專門負責評論中臺資料統計、資料重新整理等功能，這些功能對系統負載影響比較大，需要和主系統解耦。

從上圖可以看到，整個監聽模組包括了”bees採集“和”業務事件平臺“兩個部分，一個負責採集，一個負責對事件進行處理和分發，這裡為什麼還需要一個獨立的平臺進行事件處理和分發，有2個原因：

直接採集的事件，其事件內容依然無法滿足業務需求，無法滿足對比變更前後的資料來自定義事件，因此需要對相應的事件資料進行合併，具體的實現在後文進行介紹。
變更事件需要按照業務方自定義的條件進行過濾，只需要將滿足條件的事件分發給下游資料服務。

因此這裡複用了vivo自研的業務事件平臺，通過low Code方式對事件資料進行處理和過濾後，發給下游的資料服務，整個流程為bees採集—>事件平臺—>評論資料服務，接下來我們先介紹下MongoDB的採集系統部分。

MongoDB採集架構和流程

對於MongoDB的採集，我們複用了vivo自研的在Bees大資料採集平臺能力，基於這個平臺的DB資料採集的子元件（bees-dbsync），我們開發了用於 MongoDB的資料採集的鏈路，適用於實時獲取MongoDB的變更資訊，實現了對於MongoDB的全量和增量的採集能力。

功能介紹

現階段MongoDB採集模組可以支援的功能如下：

支援在任務接入後進行一次全量採集，全量採集結束後會根據使用者配置的延遲時間開啟增量採集。
支援針對單一任務的啟動、停止、修改等操作。操作完成後會實時進行相應的變更。
增量採集斷點續傳功能。在任意時刻停止任務後進行恢復採集，任務將由上一次完成的採集點位後一個點位開始繼續進行採集。在oplog大小保證資料完整的條件下，不會有資料漏採的情況發生。
全量、增量採集均支援按照使用者自定義的kafka分割槽傳送規則傳送至相應的分割槽。
全量、增量採集均支援任務狀態和資料量監控。
全量、增量採集均支援根據副本集、sharding變化自動開啟採集。

方案架構

在採集系統中，關於MongoDB的採集模組架構圖如下：

採集系統中，MongoDB採集模組內部結構如上圖橙色方框內所示。主要包括：

MongoDBParser首先將對資料進行解析和過濾。對於MongoDB全量資料採集，MongoDBParser將直接對全表執行find()操作，對於MongoDB 增量資料採集，MongoDBParser將讀取local庫下的oplog.rs表，根據遞增的ts值依次獲取新增的oplog事件，由於ts值的唯一性，已經傳送完成的 ts值將作為歷史點位資訊儲存在Bees-DBSync本地並上傳到Bees-Manager的資料庫中，成為斷點續傳功能的必須條件。
StreamData，具體由MongoDBStreamData實現，負責存放Bees-DBSync從業務MongDB解析後的資料。
PackageThread，負責對MongoDBStreamData格式的資料進行任務資訊的填充，並將資料打包成統一的PkgData資料格式，用以保證MongoDB、MySQL等傳送格式的一致性。
PkgData，是Bees-DBSync內部處理後統一的資料格式。
KafkaSink模組，負責對目的端資訊進行處理，根據使用者配置的不同分割槽傳送規則，將PkgData格式的資料傳送到不同的Kafka分割槽。

資料完整性保障

借鑑了RingBuffer設計思路：

定義了三個點位：

Pull：最後一次拉取oplog的點位
Sink：最後一次傳送Kafka的點位
Ack：最後一次成功Sink到Kafka的點位

三個點位的關係是Ack <= Sink <= Pull，三個點位記錄了日誌採集情況，出現異常情況時可以從記錄的點位恢復採集，最終保障資料完整性。

採集流程

MongoDB採集任務執行流程圖如下：

以上部分是採集系統的整理架構和流程，接下來介紹下，對變更事件進行合併和處理的架構和流程。

MongoDB變更事件處理平臺

在這裡我們複用了vivo自研的事件處理平臺的能力，新增了對MongoDB變更事件的處理，這個平臺的建設目的是面向我們的服務端開發同學，通過畫布拖拽方式幫助業務對採集到的儲存變更事件進行處理和分發。平臺提供了一個低延遲的流式處理解決方案，支援畫布的方式對採集到的MongoDB變更事件進行過濾（filter）、轉化處理（map、udf）和輸出（sink），支援UDF外掛的方式自定義處理採集到的資料，並將處理的資料分發到不同的輸出端。目前支援將MongoDB採集的事件通過filter、map後sink到es，hbase，kafka，rabbitmq以及通過dubbo方式通知到不同下游。

業務事件平臺的整體架構圖

在評論中臺的業務場景中，評論中臺需要依據MongoDB欄位發生變更的條件來進行過濾和統計，例如，需要更加欄位“commentNum”進行判斷，當前欄位的值是否是從少變多，是否數值有增加，這就需要根據MongoDB的變更前的值以及變更後的值進行比較，對符合評論業務場景條件的文件內容進行向下傳遞，因此我們需要捕獲到MongoDB變更前的值，以及未變更欄位的值。

如下圖所示，需要集合對Oplog的變更事件的採集，組合成完整的文件內容，當前文件內容放在data屬性下，old屬性下為涉及到修改的欄位在變更前的值。

但是我們發現，採集MongoDB的Oplog或者基於change stream都無法完全滿足我們的需求。

MongoDB原生的Oplog不同於binlog，Oplog只包含當前變更的欄位值，Oplog缺少變更前的值，以及未變更欄位的值，change stream也無法拿到變更前的值，基於這樣的問題，我們引入Hbase欄位多版本的特性，先預熱資料到Hbase中，然後通過查詢到的欄位舊版本值，進行資料合併，構成完整的變更事件。

MongoDB 事件資料合併流程

4.寫在最後

MongoDB叢集在評論中臺專案中已上線執行了兩年，過程中完成了約20+個業務方接入，承載了百億級評論回覆資料的儲存，表現較為穩定。BSON非結構化的資料，也支撐了我們多個版本業務的快速升級。而熱門資料記憶體化儲存引擎，較大的提高了資料讀取的效率。另外我們針對MongoDB實現了非同步事件採集能力，進一步擴充套件了MongoDB的應用場景。

但對於MongoDB來說，叢集化部署是一個不可逆的過程，叢集化後也帶來了索引，分片策略等較多的限制。因此一般業務在使用MongoDB時，副本集方式就能支撐TB級別的儲存和查詢，並非一定需要使用叢集化方式。

以上內容基於MongoDB 4.0.9版本特性，和最新版本的MongoDB細節上略有差異。

關於作者：

vivo網際網路技術：百靈評論專案開發團隊，魯班事件平臺開發團隊，bees資料採集團隊

MongoDB在vivo評論中臺的應用案例