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

利用數據中心(OLTP)整合不同業務線的數據，解決數據孤島問題已經是各個互聯網企業的必用手段。

本文將分享愛奇藝內容中臺數據中心(OLTP)的設計與實現。

01

? ?方案設計與實現

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

? 2.1 方案設計目標??

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

1．數據孤島：無法全面的看到內容運營的所有數據

2．重復建設：各業務團隊均需具備同樣能力的服務建設

3．對接復雜：各業務團隊接口規范不統一，增加對接難度

4．耦合嚴重：各業務團隊因需要共享數據，導致服務嚴重互相依賴

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

為了滿足業務長遠的發展，我們還制定了一些需要達到的目標：

1．支持百億級數據的存儲

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

3．統一的字段變化消息通知

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

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

? 2.2 業務架構圖??

基于以上的目標我們設計了內容中臺數據中心的業務架構，如下圖：

圖1數據中心(OLTP)業務架構圖

數據寫入方統一將數據寫到數據中心(OLTP)，然后數據中心(OLTP)統一對外廣播字段的變化，其它業務方監聽自身關心的字段變化。同一個業務方既可以是寫入方也可以是讀取方。

? 2.3 數據一致性方案??

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

圖2數據一致性方案設計圖

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

? 2.4 數據高可用方案??

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

圖3數據高可用方案設計圖

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

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

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

? 2.5 海量數據存儲方案??

隨著互聯網的高速發展，很多業務場景的數據量都達到了上億的級別甚至更多，這就涉及到了海量數據的存儲問題。由于我們的業務場景也達到了上億的級別，所以我們設計了海量數據存儲方案。

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

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

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

02

? ?最佳實踐

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

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

圖5 消息通知SDK設計圖

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

SDK設計的關鍵點：

一、將RMQ封裝起來，降低業務方的復雜度；

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

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

? 3.2 技術難點??

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

數據庫樂觀鎖鎖粒度控制

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

我們期望A業務方保存歸屬字段時，B業務方不受影響，做到業務隔離。而A業務方樂觀鎖只控制A業務方并發保存時的數據一致性。所以我們的樂觀鎖version可以以業務方維度設計，可以做到鎖隔離和鎖粒度的控制，進而提升保存性能。

ES批量寫入

作為數據中心(OLTP)，避免不了業務方批量寫入數據的場景。而此時我們可以利用ES的Bulk API，來提升ES的寫入性能。經驗證ES的Bulk API比單條數據寫入index API性能高幾十倍（針對大數據量寫入）。

Bulk API官網地址：https://www.elastic.co/guide/en/elasticsearch/reference/7.6/docs-bulk.html#docs-bulk

ES之深度分頁查詢

ES在分頁查詢時，為避免深度翻頁對server端帶來的壓力，故默認控制檢索深度不能超過1萬條。如果我們需要實時查詢深度分頁數據時，可以使用Search After API進行查詢；如果我們需要快速查詢深度分頁數據，可以使用Scroll API進行查詢。經驗證性能遠大于深度翻頁，且無深度限制。

業務方維度控制

由于數據中心(OLTP)需要跟多個業務方交互，為了避免某個業務方流量異常影響其它業務方，我們設計了業務方維度的分布式限速，從而達到業務方之間的隔離。

03

? ?效果與展望

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

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

• 查詢業務方只需要對接數據中心(OLTP)即可獲取所需的所有內容運營數據，解決了對接復雜的問題；

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

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

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

總結

以上是生活随笔為你收集整理的爱奇艺内容中台数据中心的设计与实现的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。