本文主要講述 vivo 評(píng)論中臺(tái)在數(shù)據(jù)庫(kù)設(shè)計(jì)上的技術(shù)探索和實(shí)踐。

[[387706]]

一、業(yè)務(wù)背景

隨著公司業(yè)務(wù)發(fā)展和用戶規(guī)模的增多，很多項(xiàng)目都在打造自己的評(píng)論功能，而評(píng)論的業(yè)務(wù)形態(tài)基本類似。當(dāng)時(shí)各項(xiàng)目都是各自設(shè)計(jì)實(shí)現(xiàn)，存在較多重復(fù)的工作量;并且不同業(yè)務(wù)之間數(shù)據(jù)存在孤島，很難產(chǎn)生聯(lián)系。因此我們決定打造一款公司級(jí)的評(píng)論業(yè)務(wù)中臺(tái)，為各業(yè)務(wù)方提供評(píng)論業(yè)務(wù)的快速接入能力。在經(jīng)過(guò)對(duì)各大主流 APP 評(píng)論業(yè)務(wù)的競(jìng)品分析，我們發(fā)現(xiàn)大部分評(píng)論的業(yè)務(wù)形態(tài)都具備評(píng)論、回復(fù)、二次回復(fù)、點(diǎn)贊等功能。

具體如下圖所示：

涉及到的核心業(yè)務(wù)概念有：

• 【主題 topic】評(píng)論的主題，商城的商品、應(yīng)用商店的 APP、社區(qū)的帖子
• 【評(píng)論 comment】用戶針對(duì)于主題發(fā)表的內(nèi)容
• 【回復(fù) reply】用戶針對(duì)于某條評(píng)論發(fā)表的內(nèi)容，包括一級(jí)回復(fù)和二級(jí)回復(fù)

二、數(shù)據(jù)庫(kù)存儲(chǔ)的選擇

團(tuán)隊(duì)在數(shù)據(jù)庫(kù)選型設(shè)計(jì)時(shí)，對(duì)比了多種主流的數(shù)據(jù)庫(kù)，最終在 MySQL 和 MongoDB 兩種存儲(chǔ)之進(jìn)行抉擇。

由于評(píng)論業(yè)務(wù)的特殊性，它需要如下能力：

• 【字段擴(kuò)展】業(yè)務(wù)方不同評(píng)論模型存儲(chǔ)的字段有一定差異，需要支持動(dòng)態(tài)的自動(dòng)擴(kuò)展。
• 【海量數(shù)據(jù)】作為公司中臺(tái)服務(wù)，數(shù)據(jù)量隨著業(yè)務(wù)方的增多成倍增長(zhǎng)，需要具備快速便捷的水平擴(kuò)展和遷移能力。
• 【高可用】作為中臺(tái)產(chǎn)品，需要提供快速和穩(wěn)定的讀寫能力，能夠讀寫分離和自動(dòng)恢復(fù)。

而評(píng)論業(yè)務(wù)不涉及用戶資產(chǎn)，對(duì)事務(wù)的要求性不高。因此我們選用了 MongoDB 集群 作為最底層的數(shù)據(jù)存儲(chǔ)方式。

三、深入了解 MongoDB

1.集群架構(gòu)

由于單臺(tái)機(jī)器存在磁盤/IO/CPU等各方面的瓶頸，因此以 MongoDB 提供集群方式的部署架構(gòu)，如圖所示:

主要由以下三個(gè)部分組成：

• mongos：路由服務(wù)器，負(fù)責(zé)管理應(yīng)用端的具體鏈接。應(yīng)用端請(qǐng)求到mongos服務(wù)后，mongos把具體的讀寫請(qǐng)求轉(zhuǎn)發(fā)到對(duì)應(yīng)的shard節(jié)點(diǎn)上執(zhí)行。一個(gè)集群可以有1~N個(gè)mongos節(jié)點(diǎn)。
• config：配置服務(wù)器，用于分存儲(chǔ)分片集合的元數(shù)據(jù)和配置信息，必須為 復(fù)制集(關(guān)于復(fù)制集概念戳我) 方式部署。mongos通過(guò)config配置服務(wù)器合的元數(shù)據(jù)信息。
• shard：用于存儲(chǔ)集合的分片數(shù)據(jù)的mongod服務(wù)，同樣必須以 復(fù)制集 方式部署。

2.片鍵

MongoDB 數(shù)據(jù)是存在collection(對(duì)應(yīng) MySQL表)中。集群模式下，collection按照 片鍵(shard key)拆分成多個(gè)區(qū)間，每個(gè)區(qū)間組成一個(gè)chunk，按照規(guī)則分布在不同的shard中。并形成元數(shù)據(jù)注冊(cè)到config服務(wù)中管理。

分片鍵只能在分片集合創(chuàng)建時(shí)指定，指定后不能修改。分片鍵主要有兩大類型：

• hash分片：通過(guò)hash算法進(jìn)行散列，數(shù)據(jù)分布得更加平均和分散。支持單列和多列hash。
• 范圍分片：按照指定片鍵的值分布，連續(xù)的key往往分布在連續(xù)的區(qū)間，更加適用范圍查詢場(chǎng)景。單數(shù)據(jù)散列性由分片鍵本身保證。

3.評(píng)論中臺(tái)的實(shí)踐

1)集群的擴(kuò)展

作為中臺(tái)服務(wù)，對(duì)于不同的接入業(yè)務(wù)方，通過(guò)表隔離來(lái)區(qū)分?jǐn)?shù)據(jù)。以comment評(píng)論表舉例，每個(gè)接入業(yè)務(wù)方都單獨(dú)創(chuàng)建一張表，業(yè)務(wù)方A表為 comment_clientA ，業(yè)務(wù)方B表為 comment_clientB，均在接入時(shí)創(chuàng)建表和相應(yīng)索引信息。但只是這樣設(shè)計(jì)存在幾個(gè)問(wèn)題：

單個(gè)集群，不能滿足部分業(yè)務(wù)數(shù)據(jù)物理隔離的需要。

集群調(diào)優(yōu)(如split遷移時(shí)間)很難業(yè)務(wù)特性差異化設(shè)置。

水平擴(kuò)容帶來(lái)的單個(gè)業(yè)務(wù)方數(shù)據(jù)過(guò)于分散問(wèn)題。

因此我們擴(kuò)展了 MongoDB的集群架構(gòu)：

擴(kuò)展后的評(píng)論MongoDB集群 增加了 【邏輯集群】和【物理集群】的概念。一個(gè)業(yè)務(wù)方屬于一個(gè)邏輯集群，一個(gè)物理集群包含多個(gè)邏輯集群。

增加了路由層設(shè)計(jì)，由應(yīng)用負(fù)責(zé)擴(kuò)展Spring的MongoTemplate和連接池管理，實(shí)現(xiàn)了業(yè)務(wù)到MongoDB集群之間的切換選擇服務(wù)。

不同的MongoDB分片集群，實(shí)現(xiàn)了物理隔離和差異調(diào)優(yōu)的可能。

2)片鍵的選擇

MongoDB集群中，一個(gè)集合的數(shù)據(jù)部署是分散在多個(gè)shard分片和chunk中的，而我們希望一個(gè)評(píng)論列表的查詢最好只訪問(wèn)到一個(gè)shard分片，因此確定了 范圍分片 的方式。

起初設(shè)置只使用單個(gè)key作為分片鍵，以comment評(píng)論表舉例，主要字段有{"_id":唯一id,"topicId":主題id,"text":文本內(nèi)容,"createDate":時(shí)間} ,考慮到一個(gè)主題id的評(píng)論盡可能連續(xù)分布，我們?cè)O(shè)置的分片鍵為 topicId。隨著性能測(cè)試的介入，我們發(fā)現(xiàn)了有兩個(gè)非常致命的問(wèn)題：

jumbo chunk問(wèn)題

唯一鍵問(wèn)題

jumbo chunk：

• 官方文檔中，MongoDB中的chunk大小被限制在了1M-1024M。分片鍵的值是chunk劃分的唯一依據(jù)，在數(shù)據(jù)量持續(xù)寫入超過(guò)chunk size設(shè)定值時(shí)，MongoDB 集群就會(huì)自動(dòng)的進(jìn)行分裂或遷移。而對(duì)于同一個(gè)片鍵的寫入是屬于一個(gè)chunk，無(wú)法被分裂，就會(huì)造成 jumbo chunk 問(wèn)題。

舉例，若我們?cè)O(shè)置1024M為一個(gè)chunk的大小，單個(gè)document 5KB計(jì)算，那么單個(gè)chunk能夠存儲(chǔ)21W左右document?？紤]熱點(diǎn)的主題評(píng)論(如微信評(píng)論)，評(píng)論數(shù)可能達(dá)到40W+，因此單個(gè)chunk很容易超過(guò)1024M。超過(guò)最大size的chunk依然能夠提供讀寫服務(wù)，只是不會(huì)再進(jìn)行分裂和遷移，長(zhǎng)久以往會(huì)造成集群之間數(shù)據(jù)的不平衡。

唯一鍵問(wèn)題：

• MongoDB 集群的唯一鍵設(shè)置增加了限制，必須是包含分片鍵的;如果_id不是分片鍵，_id索引只能保證單個(gè)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
• 因此我們刪除了數(shù)據(jù)和集合，調(diào)整 topicId 和 _id 為聯(lián)合分片鍵 重新創(chuàng)建了集合。這樣即打破了chunk size的限制，也解決了唯一性問(wèn)題。

4.遷移和擴(kuò)容

隨著數(shù)據(jù)的寫入，當(dāng)單個(gè)chunk中數(shù)據(jù)大小超過(guò)指定大小時(shí)(或chunk中的文件數(shù)量超過(guò)指定值)。MongoDB集群會(huì)在插入或更新時(shí)，自動(dòng)觸發(fā)chunk的拆分。

拆分會(huì)導(dǎo)致集合中的數(shù)據(jù)塊分布不均勻，在這種情況下，MongoDB balancer組件會(huì)觸發(fā)集群之間的數(shù)據(jù)塊遷移。balancer組件是一個(gè)管理數(shù)據(jù)遷移的后臺(tái)進(jìn)程，如果各個(gè)shard分片之間的chunk數(shù)差異超過(guò)閾值，balancer會(huì)進(jìn)行自動(dòng)的數(shù)據(jù)遷移。

balancer是可以在線對(duì)數(shù)據(jù)遷移的，但是遷移的過(guò)程中對(duì)于集群的負(fù)載會(huì)有較大影響。一般建議可以通過(guò)如下設(shè)置，在業(yè)務(wù)低峰時(shí)進(jìn)行(更多見(jiàn)官網(wǎng))

MongoDB的擴(kuò)容也非常簡(jiǎn)單，只需要準(zhǔn)備好新的shard復(fù)制集后，在 Mongos節(jié)點(diǎn)中執(zhí)行：

擴(kuò)容期間因?yàn)閏hunk的遷移，同樣會(huì)導(dǎo)致集群可用性降低，因此只能在業(yè)務(wù)低峰進(jìn)行

四、寫在最后

MongoDB集群在評(píng)論中臺(tái)項(xiàng)目中已上線運(yùn)行了一年多，過(guò)程中完成了約10個(gè)業(yè)務(wù)方接入，承載了1億+評(píng)論回復(fù)數(shù)據(jù)的存儲(chǔ)，表現(xiàn)較為穩(wěn)定。BSON非結(jié)構(gòu)化的數(shù)據(jù)，也支撐了我們多個(gè)版本業(yè)務(wù)的快速升級(jí)。而熱門數(shù)據(jù)內(nèi)存化存儲(chǔ)引擎，較大地提高了數(shù)據(jù)讀取的效率。

但對(duì)于MongoDB來(lái)說(shuō)，集群化部署是一個(gè)不可逆的過(guò)程，集群化后也帶來(lái)了索引，分片策略等較多的限制。因此一般業(yè)務(wù)在使用MongoDB時(shí)，副本集方式就能支撐TB級(jí)別的存儲(chǔ)和查詢，并非一定需要使用集群化方式。

以上內(nèi)容基于MongoDB 4.0.9版本特性，和最新版本的MongoDB細(xì)節(jié)上略有差異。