任芳琴

（浙江廣播電視集團(tuán)，浙江 杭州 310005）

0 引言

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

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

1 設(shè)計(jì)思路

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.1 實(shí)現(xiàn)機(jī)制

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

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

消息服務(wù)通過訂閱消息隊(duì)列，對(duì)用戶操作引起的數(shù)據(jù)變化進(jìn)行監(jiān)聽，如新建稿件或者素材上載。消息服務(wù)接收消息，進(jìn)行消息過濾。消息服務(wù)接收消息后，開始掃描變更數(shù)據(jù)，并根據(jù)系統(tǒng)策略配置完成數(shù)據(jù)同步范圍、周期、同步源的設(shè)定。設(shè)定完成后，系統(tǒng)自動(dò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ù)報(bào)協(xié)議（User Datagram Protocol，UDP）多鏈路傳輸。對(duì)端數(shù)據(jù)中心的傳輸服務(wù)開始接收數(shù)據(jù)，接收完成后，由流程服務(wù)開始入庫流程，完成數(shù)據(jù)校對(duì)后，完成數(shù)據(jù)入庫。

2.2 最終一致性

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

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

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

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

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

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

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

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

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

4 結(jié)語

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