新聞制播系統(tǒng)云容災(zāi)數(shù)據(jù)同步方案設(shè)計與實踐

任芳琴

（浙江廣播電視集團，浙江 杭州 310005）

0 引言

新聞制播系統(tǒng)是電視臺的重要信息系統(tǒng)，業(yè)務(wù)連續(xù)性要求高，因此在系統(tǒng)設(shè)計和建設(shè)過程中，除了采用服務(wù)集群化部署、負載均衡、網(wǎng)絡(luò)堆疊等多種措施確保系統(tǒng)本身的穩(wěn)定性，還會考慮搭建災(zāi)備系統(tǒng)，提高可用性。

電視臺以媒體數(shù)據(jù)作為節(jié)目生產(chǎn)的核心要素，視音頻素材、圖片等非結(jié)構(gòu)化數(shù)據(jù)占整體數(shù)據(jù)的90%以上，且隨著近些年分布式存儲的發(fā)展及性價比提升，在線數(shù)據(jù)存儲周期變長。以浙江廣播電視集團新聞制播系統(tǒng)為例，在線數(shù)據(jù)容量常年在500 TB以上。因此，如果存儲發(fā)生故障或發(fā)生人為誤操作，數(shù)據(jù)恢復(fù)時間（Recovery Time Object，RTO）很有可能超過新聞生產(chǎn)業(yè)務(wù)連續(xù)性要求的閾值，最終造成節(jié)目來不及制作、無法播出等重大播出事故。對此，構(gòu)建一套高效、可靠、可行的容災(zāi)方案，針對數(shù)據(jù)庫層、存儲層的數(shù)據(jù)容災(zāi)是關(guān)鍵[1]。

1 設(shè)計思路

本文介紹的新聞制播系統(tǒng)的數(shù)據(jù)容災(zāi)基于媒體私有云平臺，兩者采用異址多活的設(shè)計思路。新聞制播系統(tǒng)（以下稱本地系統(tǒng)）采用本地化部署設(shè)計，各類服務(wù)組件、應(yīng)用均部署在物理機上，視音頻素材、圖片、故事板等非結(jié)構(gòu)化數(shù)據(jù)存儲于分布式存儲上，存儲文稿數(shù)據(jù)、系統(tǒng)配置信息和業(yè)務(wù)過程數(shù)據(jù)采用MySQL 數(shù)據(jù)庫。媒體私有云平臺采用多租戶模式，其平臺服務(wù)層（Platform as a Service，PaaS）能夠為上層業(yè)務(wù)系統(tǒng)提供各類公共服務(wù)，包括媒體服務(wù)、數(shù)據(jù)庫服務(wù)及中間件等各類通用服務(wù)，滿足節(jié)目生產(chǎn)所需[2]。

云平臺與本級系統(tǒng)之間數(shù)據(jù)實時雙向同步，保持媒體內(nèi)容（元數(shù)據(jù)、代理碼率、媒體素材等）一致。正常情況下，本地系統(tǒng)和云平臺相互獨立運行，互不依賴?；谝恢滦缘拿襟w內(nèi)容，浙江廣播電視集團采用以下業(yè)務(wù)模式：大屏新聞節(jié)目的采編播流程主要使用本地制播系統(tǒng)的功能模塊資源，新媒體服務(wù)業(yè)務(wù)則選用云平臺的功能模塊資源。應(yīng)急情況下，若本級系統(tǒng)出現(xiàn)問題無法使用，云平臺的彈性可快速實現(xiàn)所需資源的調(diào)配，通過手動修改后臺策略設(shè)置，將后端服務(wù)指向云平臺側(cè)，提供持續(xù)業(yè)務(wù)生產(chǎn)能力。總體設(shè)計思路如圖1 所示。

圖1 容災(zāi)總體設(shè)計思路

1.1 數(shù)據(jù)同步總體設(shè)計原則

實現(xiàn)容災(zāi)的關(guān)鍵設(shè)計要素是數(shù)據(jù)的同步。數(shù)據(jù)同步總體設(shè)計原則[3]如下。

第一，本地系統(tǒng)與云平臺之間具備持續(xù)性、高效、高可靠的數(shù)據(jù)傳輸鏈路和傳輸協(xié)議。

第二，同步的數(shù)據(jù)包括用戶數(shù)據(jù)、文稿數(shù)據(jù)、時間線數(shù)據(jù)、視頻素材數(shù)據(jù)、后期包裝圖片以及字幕動畫數(shù)據(jù)等。支持對數(shù)據(jù)操作的同步，比如對數(shù)據(jù)的刪除、數(shù)據(jù)的元數(shù)據(jù)屬性編輯。

第三，任意一方數(shù)據(jù)中心的數(shù)據(jù)發(fā)生變化，都將變化同步到另一方。數(shù)據(jù)接受方應(yīng)禁止訪問未同步完成的數(shù)據(jù)并給出明確的提示。

第四，任何時候都要保證雙方數(shù)據(jù)的一致性和完整性。任何一方的后臺服務(wù)或數(shù)據(jù)宕機癱瘓不能影響另一方的正常運行，并能繼續(xù)生產(chǎn)節(jié)目。

第五，需要對數(shù)據(jù)同步進行統(tǒng)一監(jiān)控和管理，第一時間發(fā)現(xiàn)潛在異常，以免影響業(yè)務(wù)的正常運轉(zhuǎn)。

第六，如遇同步鏈路中斷，恢復(fù)后自動完成未完成的復(fù)制任務(wù)，保持數(shù)據(jù)的最終一致性。

1.2 同步數(shù)據(jù)類型

從業(yè)務(wù)角度分析，雙數(shù)據(jù)中心間可同步的數(shù)據(jù)對象包括媒體元數(shù)據(jù)、視音頻、圖片等媒體文件、非編工程文件及元數(shù)據(jù)、文稿及串聯(lián)單等。根據(jù)類型的不同，不同數(shù)據(jù)采用不同的同步機制。

2 雙向同步的實現(xiàn)

2.1 實現(xiàn)機制

同步服務(wù)模塊由消息服務(wù)、流程服務(wù)、傳輸服務(wù)3 個部分組成，用于提供本地系統(tǒng)和云平臺兩個數(shù)據(jù)中心之間的數(shù)據(jù)同步服務(wù)。消息服務(wù)通過收集系統(tǒng)中數(shù)據(jù)變化的通知消息，對其進行判斷過濾，進而執(zhí)行同步策略，驅(qū)動流程服務(wù)進行同步流程操作。流程服務(wù)接受消息服務(wù)發(fā)送的同步請求，執(zhí)行數(shù)據(jù)同步流程。傳輸服務(wù)提供需要同步數(shù)據(jù)的傳輸。3 個服務(wù)之間通過REST 接口交互。通過消息、流程、傳輸3 個服務(wù)的配合，完成數(shù)據(jù)的同步備份，如圖2所示，主要步驟如下。

圖2 同步服務(wù)模塊

消息服務(wù)通過訂閱消息隊列，對用戶操作引起的數(shù)據(jù)變化進行監(jiān)聽，如新建稿件或者素材上載。消息服務(wù)接收消息，進行消息過濾。消息服務(wù)接收消息后，開始掃描變更數(shù)據(jù)，并根據(jù)系統(tǒng)策略配置完成數(shù)據(jù)同步范圍、周期、同步源的設(shè)定。設(shè)定完成后，系統(tǒng)自動執(zhí)行同步。流程服務(wù)發(fā)起同步流程，生成傳輸任務(wù)（文件、元數(shù)據(jù)、基礎(chǔ)數(shù)據(jù)類型）發(fā)給傳輸服務(wù)。傳輸服務(wù)開始傳輸數(shù)據(jù)，元數(shù)據(jù)使用超文本傳輸安全協(xié)議（Hypertext Transfer Protocol Secure，HTTPS）調(diào)用RestFul 接口傳輸，媒體文件采用自定義用戶數(shù)據(jù)報協(xié)議（User Datagram Protocol，UDP）多鏈路傳輸。對端數(shù)據(jù)中心的傳輸服務(wù)開始接收數(shù)據(jù)，接收完成后，由流程服務(wù)開始入庫流程，完成數(shù)據(jù)校對后，完成數(shù)據(jù)入庫。

2.2 最終一致性

數(shù)據(jù)同步遵循最終一致性原則。為此，需要解決兩個問題。一是數(shù)據(jù)同步帶來的數(shù)據(jù)版本管理的問題[4]。比如正常情況下，本地系統(tǒng)和云平臺的上層應(yīng)用可能同時打開同一份稿件或時間線，這時雙向同步便產(chǎn)生多個數(shù)據(jù)版本，產(chǎn)生數(shù)據(jù)混亂。對此，通過增加控制標識（云端或本地），確保同一時刻只更新一端數(shù)據(jù)庫，即應(yīng)用只讀取/寫入使用一個數(shù)據(jù)中心的數(shù)據(jù)，另一份數(shù)據(jù)中心的數(shù)據(jù)只是同步更新，以此規(guī)避多版本管理的問題。對于記者編輯來說，無論使用本地或是云平臺的應(yīng)用，只有設(shè)置當前系統(tǒng)標識的稿件、節(jié)目時間線等才能被打開并編輯，否則就只會提示只讀打開。二是數(shù)據(jù)同步失敗的處理。在系統(tǒng)維護層面，對數(shù)據(jù)同步過程的監(jiān)控和管理是確保準確性的重要一環(huán)。為此，系統(tǒng)為運維人員提供同步監(jiān)控管理界面（如圖3 所示），實時追蹤數(shù)據(jù)同步狀態(tài)和進度，及時捕捉并應(yīng)對異常情況。對于沒有完成同步或者同步到對端元數(shù)據(jù)有問題的情況，可以刪除有問題的對端同步文件，并通過同步工具重新發(fā)起同步流程。在應(yīng)用層面，如果記者編輯打開了正在同步的時間線或者同步失敗，應(yīng)用軟件便會給出相應(yīng)的提示。

圖3 同步監(jiān)控界面

2.3 數(shù)據(jù)同步的可靠性

在網(wǎng)絡(luò)層，本地系統(tǒng)與云平臺兩個數(shù)據(jù)中心通過冗余網(wǎng)絡(luò)鏈路聯(lián)通。為確保同步服務(wù)的穩(wěn)定性，進行了以下調(diào)優(yōu)。第一，因同步服務(wù)數(shù)據(jù)庫數(shù)據(jù)量較大，同步數(shù)據(jù)庫與業(yè)務(wù)核心數(shù)據(jù)庫分開，單獨創(chuàng)建數(shù)據(jù)庫部署在同步服務(wù)器上。第二，本地系統(tǒng)側(cè)和云平臺側(cè)均采用集群化部署，即使某同步服務(wù)器出現(xiàn)鏈路斷開或服務(wù)異常的情況，集群中的其他服務(wù)器會接管繼續(xù)執(zhí)行同步任務(wù)。第三，為防止單臺服務(wù)器負載過大導(dǎo)致服務(wù)宕機，由流程服務(wù)產(chǎn)生的任務(wù)調(diào)度模式采用負載均衡模式，并可根據(jù)實際情況設(shè)置最大任務(wù)數(shù)量。第四，根據(jù)每天同步的數(shù)據(jù)量以及同步服務(wù)器之間的帶寬，傳輸服務(wù)設(shè)置最大傳輸執(zhí)行器，每個執(zhí)行器對應(yīng)不同的UDP 端口。

3 應(yīng)急切換測試

為保證容災(zāi)可用性，進行應(yīng)急切換測試。設(shè)置如下測試場景：本地系統(tǒng)因分布式存儲故障導(dǎo)致不可用，非編工作站訪問不到非編素材，打開時間線顯示 “media offline” ，準備進行應(yīng)急操作，將支撐非編應(yīng)用的后臺服務(wù)、數(shù)據(jù)庫和存儲快速切換到云平臺，云平臺按需調(diào)配資源。

非編軟件配置信息主要做以下更改：將非編軟件所訪問的CMS 服務(wù)和中間件、數(shù)據(jù)庫等后臺服務(wù)網(wǎng)際互連協(xié)議（Internet Protocol，IP）地址從本地系統(tǒng)更改為云平臺，向云平臺的服務(wù)注冊非編工作站終端IP 地址，非編工作站掛載云平臺的存儲，更改非編軟件的登錄認證信息，并改向藍云的輕型目錄訪問協(xié)議（Lightweight Directory Access Protocol，LDAP）認證。為簡化切換操作，做到快速切換，技術(shù)人員提前將相關(guān)配置寫入配置文件，切換時，直接進行配置文件替換即可。

后臺服務(wù)和存儲切換成功后，如果時間線的控制標識是 “本地系統(tǒng)” ，需要將該控制標識切至 “云平臺” ，在時間線上右鍵刷新并打開時間線，時間線成功識別到云平臺素材，能夠正常進行編輯操作。編輯完成后，發(fā)送合成并審核通過。審核通過后，演播室播出。整個演練流程[5]，如圖4 所示。

圖4 應(yīng)急切換演練流程

4 結(jié)語

制播系統(tǒng)的容災(zāi)多種多樣，有些是建設(shè)最小應(yīng)急系統(tǒng)，有些則是簡單地通過配置雙體存儲確保數(shù)據(jù)高可用。但是這些方式的資源調(diào)配都不夠靈活，或者只能起到數(shù)據(jù)備份的作用，或者應(yīng)急生產(chǎn)規(guī)模縮小，而且從經(jīng)濟角度講，需要投入一套包括軟件、計算、存儲及網(wǎng)絡(luò)等在內(nèi)的重復(fù)資源。相比傳統(tǒng)的災(zāi)備方式，借助云平臺進行災(zāi)備，提高了資源利用效率，且真正獲得了一套完整生產(chǎn)系統(tǒng)克隆的能力。相信云上災(zāi)備的解決方案將越來越被行業(yè)所認可。