互聯(lián)網(wǎng)技術(shù)發(fā)展至今，當業(yè)務(wù)復(fù)雜度比較高的時候，采用微服務(wù)化是一個有效的手段，但是隨著服務(wù)的拆分，數(shù)據(jù)管理工作變得極具挑戰(zhàn)。數(shù)據(jù)中心(OLTP)通過對數(shù)據(jù)的統(tǒng)一收集和管理，一方面可以建立數(shù)據(jù)之間的聯(lián)系，從而帶來更大的價值；另一方面還可以提供強大的數(shù)據(jù)閱覽、數(shù)據(jù)分析、挖掘數(shù)據(jù)等能力，進而為企業(yè)創(chuàng)造價值收益。數(shù)據(jù)中心(OLTP)不僅可以為不同業(yè)務(wù)線屏蔽技術(shù)難點，還可以降低業(yè)務(wù)邏輯開發(fā)的復(fù)雜度，使得開發(fā)同學能夠?qū)Ｗ⒂跇I(yè)務(wù)邏輯的開發(fā)。

利用數(shù)據(jù)中心(OLTP)整合不同業(yè)務(wù)線的數(shù)據(jù)，解決數(shù)據(jù)孤島問題已經(jīng)是各個互聯(lián)網(wǎng)企業(yè)的必用手段。

本文將分享愛奇藝內(nèi)容中臺數(shù)據(jù)中心(OLTP)的設(shè)計與實現(xiàn)。

01方案設(shè)計與實現(xiàn)

之前各個業(yè)務(wù)線自己維護自己的數(shù)據(jù)和接口，這樣既不利于第三方的接入，也浪費了人力進行重復(fù)建設(shè)，為了解決諸多類似問題，我們進行了如下設(shè)計。

2.1 方案設(shè)計目標

首先我們梳理了目前系統(tǒng)存在的各種亟待解決的問題：

1．數(shù)據(jù)孤島：無法全面的看到內(nèi)容運營的所有數(shù)據(jù)

2．重復(fù)建設(shè)：各業(yè)務(wù)團隊均需具備同樣能力的服務(wù)建設(shè)

3．對接復(fù)雜：各業(yè)務(wù)團隊接口規(guī)范不統(tǒng)一，增加對接難度

4．耦合嚴重：各業(yè)務(wù)團隊因需要共享數(shù)據(jù)，導(dǎo)致服務(wù)嚴重互相依賴

5．開發(fā)繁瑣：各業(yè)務(wù)團隊需要考慮自研數(shù)據(jù)中心(OLTP)的技術(shù)痛點和難點，無法做到專人做專事，即業(yè)務(wù)開發(fā)只關(guān)注自身

為了滿足業(yè)務(wù)長遠的發(fā)展，我們還制定了一些需要達到的目標：

1．支持百億級數(shù)據(jù)的存儲

2．支持高QPS的讀、寫請求

3．統(tǒng)一的字段變化消息通知

4．極少的運維成本，頁面操作添加字段

5．通用的查詢與保存能力，避免個性化需求帶來的額外開發(fā)成本

2.2 業(yè)務(wù)架構(gòu)圖

基于以上的目標我們設(shè)計了內(nèi)容中臺數(shù)據(jù)中心的業(yè)務(wù)架構(gòu)，如下圖：

圖1數(shù)據(jù)中心(OLTP)業(yè)務(wù)架構(gòu)圖

數(shù)據(jù)寫入方統(tǒng)一將數(shù)據(jù)寫到數(shù)據(jù)中心(OLTP)，然后數(shù)據(jù)中心(OLTP)統(tǒng)一對外廣播字段的變化，其它業(yè)務(wù)方監(jiān)聽自身關(guān)心的字段變化。同一個業(yè)務(wù)方既可以是寫入方也可以是讀取方。

2.3 數(shù)據(jù)一致性方案

由于數(shù)據(jù)中心(OLTP)將數(shù)據(jù)分別存儲到了MongoDB和ES，這樣就引入了數(shù)據(jù)一致性的問題。為了解決這個問題我們調(diào)研了業(yè)內(nèi)的一些方案最終選定了最終一致性的方案。具體設(shè)計如下圖：

圖2數(shù)據(jù)一致性方案設(shè)計圖

為了避免臟數(shù)據(jù)的產(chǎn)生，我們設(shè)計字段權(quán)限控制，字段有歸屬的業(yè)務(wù)方，非歸屬的業(yè)務(wù)方?jīng)]有權(quán)限寫入該字段。由于實際使用場景中，我們大量使用ES查詢數(shù)據(jù)，所以我們設(shè)計了MongoDB字段與ES字段的映射，業(yè)務(wù)方只需要分別創(chuàng)建MongoDB和ES的字段元數(shù)據(jù)，并建立好兩者之間的映射關(guān)系。在投遞數(shù)據(jù)的時候只需要投遞一份原始數(shù)據(jù)，我們即可保存到MongoDB和ES中。為了避免ES中字段的相互覆蓋問題，我們采取的方案是查詢MongoDB中的最新數(shù)據(jù)并根據(jù)映射關(guān)系轉(zhuǎn)化為ES結(jié)構(gòu)，然后將ES中對應(yīng)的文檔進行整體覆蓋。

2.4 數(shù)據(jù)高可用方案

數(shù)據(jù)中心(OLTP)存儲著業(yè)務(wù)的關(guān)鍵數(shù)據(jù)，其重要性不言而喻，所以一定要保證服務(wù)的高可用，所以我們設(shè)計了高可用的方案，具體如下圖：

圖3數(shù)據(jù)高可用方案設(shè)計圖

方案中為了支持海量數(shù)據(jù)存儲采用了分布式文件的存儲能力。分片MongoDB集群采用同城多地部署，達到同城多活的效果，以提升集群的容災(zāi)能力。

為了避免單點問題，我們設(shè)計了實時數(shù)據(jù)備份，利用服務(wù)配置化雙寫能力，將數(shù)據(jù)寫入備份集群。代碼層面設(shè)計數(shù)據(jù)庫切換開關(guān)，以支持主集群不可用后，可以方便的切換至備份集群，從而達到數(shù)據(jù)高可用。

為了滿足數(shù)據(jù)報表等大數(shù)據(jù)處理需求我們規(guī)劃了離線數(shù)倉，充分利用MongoDB的備用集群能力。在日常使用中，備用集群可以為大數(shù)據(jù)平臺和離線數(shù)倉提供數(shù)據(jù)支撐。離線數(shù)倉可以通過指定時間讀取備用集群數(shù)據(jù)，如將9時、12時、18時共3份快照（可根據(jù)業(yè)務(wù)自身的特征自定義快照時間）進行備份。可依據(jù)離線數(shù)倉數(shù)據(jù)來恢復(fù)指定時間點的數(shù)據(jù)。

2.5 海量數(shù)據(jù)存儲方案

隨著互聯(lián)網(wǎng)的高速發(fā)展，很多業(yè)務(wù)場景的數(shù)據(jù)量都達到了上億的級別甚至更多，這就涉及到了海量數(shù)據(jù)的存儲問題。由于我們的業(yè)務(wù)場景也達到了上億的級別，所以我們設(shè)計了海量數(shù)據(jù)存儲方案。

DB層面：DB層面使用分布式文件存儲的DB，詳見2.4中MongoDB的分片集群，支持橫向擴展，可以支撐大數(shù)據(jù)量存儲，且性能僅受限于單分片collection的數(shù)據(jù)量級。

ES層面：ES在創(chuàng)建index時需要指定索引的分片個數(shù)，一旦創(chuàng)建后不可修改，所以我們在創(chuàng)建索引時需要評估好該索引的數(shù)據(jù)量級與增長趨勢。當索引單分片的數(shù)據(jù)量級過大，會導(dǎo)致性能急劇下降，此時我們可以使用ES的reIndex API進行索引重建，但該操作會最大程度占用ESserver端的服務(wù)資源，導(dǎo)致影響正常業(yè)務(wù)。為了解決此類問題我們可以利用ES的別名Alias + 分庫分表的思路，設(shè)計出支持不受數(shù)據(jù)量級限制的ES索引。ES的別名下可掛載多個真實的索引名，而我們按照一定的規(guī)則對索引數(shù)據(jù)進行拆分，將數(shù)據(jù)寫入到拆分后的真實索引中，而真實索引掛在在同一個別名下，這樣可以做到讀業(yè)務(wù)方無感知的效果。但是ES的別名并不具備寫入能力（別名下多個索引時），所以我們需要自己執(zhí)行路由規(guī)則，進行索引拆分和寫入。具體設(shè)計方案如下圖：

圖4ES索引拆分寫入與查詢流程圖

02最佳實踐?

3.1 標準化、通用化消息通知

為了解決各業(yè)務(wù)團隊因需要共享數(shù)據(jù)，導(dǎo)致服務(wù)嚴重互相依賴的問題，我們設(shè)計了標準化、通用化的消息通知機制。用戶只需要引入數(shù)據(jù)中心(OLTP) SDK ，并做簡單的配置，便可監(jiān)聽到指定字段發(fā)生變化時的消息，以觸發(fā)自身的業(yè)務(wù)邏輯。數(shù)據(jù)中心(OLTP)消息通知 SDK 設(shè)計圖如下：

圖5 消息通知SDK設(shè)計圖

當數(shù)據(jù)中心(OLTP)的字段發(fā)生變化時，會向RMQ 消息隊列投放相關(guān)信息；SDK根據(jù)業(yè)務(wù)方配置信息會訂閱 RMQ 消息隊列，并根據(jù)用戶的訂閱配置，過濾掉用戶不關(guān)心的消息。

SDK設(shè)計的關(guān)鍵點：

一、將RMQ封裝起來，降低業(yè)務(wù)方的復(fù)雜度；

二、輕服務(wù)端重客戶端，將消息的過濾與去重放到SDK,降低服務(wù)端的壓力；

三、消息的過濾可以支持到二級字段維度，更精確的過濾掉業(yè)務(wù)方不需要的消息，減少客戶端的壓力。

3.2 技術(shù)難點

在數(shù)據(jù)中心(OLTP)的應(yīng)用實踐當中我們遇到了一些技術(shù)挑戰(zhàn)，經(jīng)過研究我們進行了很好的解決：

數(shù)據(jù)庫樂觀鎖鎖粒度控制

數(shù)據(jù)中心(OLTP)一張表中的字段都有歸屬的業(yè)務(wù)方，如果我們用一個version作為樂觀鎖控制，那A業(yè)務(wù)方在保存a字段時，B業(yè)務(wù)方就無法保存b字段，會導(dǎo)致服務(wù)性能的急劇下降，這不是我們期望的結(jié)果。

我們期望A業(yè)務(wù)方保存歸屬字段時，B業(yè)務(wù)方不受影響，做到業(yè)務(wù)隔離。而A業(yè)務(wù)方樂觀鎖只控制A業(yè)務(wù)方并發(fā)保存時的數(shù)據(jù)一致性。所以我們的樂觀鎖version可以以業(yè)務(wù)方維度設(shè)計，可以做到鎖隔離和鎖粒度的控制，進而提升保存性能。 ES批量寫入作為數(shù)據(jù)中心(OLTP)，避免不了業(yè)務(wù)方批量寫入數(shù)據(jù)的場景。而此時我們可以利用ES的Bulk API，來提升ES的寫入性能。經(jīng)驗證ES的Bulk API比單條數(shù)據(jù)寫入index API性能高幾十倍（針對大數(shù)據(jù)量寫入）。Bulk API官網(wǎng)地址：https://www.elastic.co/guide/en/elasticsearch/reference/7.6/docs-bulk.html#docs-bulk ES之深度分頁查詢ES在分頁查詢時，為避免深度翻頁對server端帶來的壓力，故默認控制檢索深度不能超過1萬條。如果我們需要實時查詢深度分頁數(shù)據(jù)時，可以使用Search After API進行查詢；如果我們需要快速查詢深度分頁數(shù)據(jù)，可以使用Scroll API進行查詢。經(jīng)驗證性能遠大于深度翻頁，且無深度限制。 業(yè)務(wù)方維度控制由于數(shù)據(jù)中心(OLTP)需要跟多個業(yè)務(wù)方交互，為了避免某個業(yè)務(wù)方流量異常影響其它業(yè)務(wù)方，我們設(shè)計了業(yè)務(wù)方維度的分布式限速，從而達到業(yè)務(wù)方之間的隔離。

03效果與展望

數(shù)據(jù)中心(OLTP)上線后，可以看到內(nèi)容運營的所有數(shù)據(jù)，解決了數(shù)據(jù)孤島問題；

各寫入方只需要按規(guī)范將數(shù)據(jù)投遞給數(shù)據(jù)中心(OLTP)即可對外提供數(shù)據(jù)，解決了重復(fù)建設(shè)的問題；

查詢業(yè)務(wù)方只需要對接數(shù)據(jù)中心(OLTP)即可獲取所需的所有內(nèi)容運營數(shù)據(jù)，解決了對接復(fù)雜的問題；

各業(yè)務(wù)團隊統(tǒng)一從數(shù)據(jù)中心(OLTP)獲取需要的數(shù)據(jù)，不再需要跟數(shù)據(jù)寫入方交互，解決了業(yè)務(wù)系統(tǒng)耦合嚴重的問題。

目前數(shù)據(jù)中心(OLTP)已對接26個業(yè)務(wù)方，部署物理隔離的獨立集群4套，流量較大的集群，讀QPS超過2K，寫入QPS超過500，最大的表數(shù)據(jù)量已達2.5億。

當然數(shù)據(jù)中心(OLTP)還需要持續(xù)建設(shè)，為了數(shù)據(jù)的高可用我們設(shè)計了主備集群，但這樣也帶來了主備集群間的數(shù)據(jù)一致性問題——數(shù)據(jù)中心的數(shù)據(jù)量會越來越大。為了看到整個數(shù)據(jù)的全貌，傳統(tǒng)的技術(shù)已經(jīng)無法解決，我們目前正在打通此系統(tǒng)與離線數(shù)據(jù)平臺(OLAP)平臺的通路，借助實時數(shù)倉與離線數(shù)倉的技術(shù)，全面賦能業(yè)務(wù)需要。