一.引言
     2009年2月18日至28日，在哈爾濱舉辦了第二十四界世界大學生冬季運動會（簡稱“大冬會”），此次大冬會是歷史上比賽項目設置最多的一屆盛會，共設有12個大項，82個小項。其中冰上5個大項在哈爾濱市舉行，共計33個小項；雪上5個大項在亞布力進行，也是共計33個小項；剩余2個雪上大項（共計16個小項）則在帽兒山進行。

二.總體需求與系統架構
     本屆大冬會在三個賽區同時進行，分別是：哈爾濱、亞布力、帽兒山。為實現這三個賽區的賽事資料共享，系統采用主IBC（哈爾濱）+分IBC（亞布力）+制作區（帽兒山）的方式設計，主分IBC之間采用光纖連接，通過遠程IP高速傳輸方式實現主分IBC之間賽事資料的同步，帽兒山的賽事信息通過衛星方式傳回哈爾濱的主IBC。各系統銜接關系如圖1所示。

圖1 第24屆大冬會系統總體結構

     圖中MCS總控信號調度位于哈爾濱，亞布力、帽兒山的一些比賽將會通過衛星實時傳回哈爾濱的主IBC，其中亞布力通過衛星回傳的信號僅僅是作為一種備份手段，也就是在主分IBC之間通過光纜傳輸的IP鏈路發生故障的情況下才會啟用。由于帽兒山賽區和主IBC之間采用衛星信號傳輸，在主IBC完成賽事收錄，所以本文主要介紹一下關鍵的主分IBC系統之間的互聯技術。

三.主分IBC互聯主要技術要求
     本屆大冬會根據自身的具體情況，創新性地提出采用主、分IBC的方式構建一套全高清的賽事資料共享系統，其中主IBC（哈爾濱）要求能夠同時收錄7路高清賽事視音頻信號，分IBC要能夠同時收錄3路高清賽事視音頻信號。要求在收錄的過程中，兩個IBC能夠立即互相同步收錄的低碼視音頻文件，延時不超過3分鐘，也就是說，在收錄時按照每隔10分鐘進行分段的情況下，要保證每段10分鐘的低碼素材在3分鐘之內傳輸到另外一個IBC。在當日比賽結束后，要把分IBC（亞布力）的高碼素材自動回傳到主IBC（哈爾濱），保證主IBC賽事資料的完整性。同時為了滿足在亞布力新聞記者的工作需要，允許亞布力記者直接使用從哈爾濱同步到亞布力的低碼素材進行節目創作，在打包合成時，或者在下載輸出時，再通過非線性編輯軟件，從主IBC直接剪切需要的高碼素材片段，這樣可以降低分IBC的存儲要求，同時也減少了傳輸帶寬壓力。在這整個的過程中涉及以下關鍵技術點：
     1.賽事信息同步
     賽事信息的創建是在IBC的收錄系統中完成的，在編排收錄計劃的時候就已經完成了賽事信息的輸入。該信息需要主分IBC之間能夠準實時的同步，以便主分IBC中的用戶，能夠及時了解哈爾濱和亞布力兩個賽區當前進行或即將進行的比賽。賽事信息可能會有調整，這就要求主分IBC同步系統要支持賽事信息修改操作的自動同步。
     2.場記信息同步
     在賽事收錄期間，會安排專人使用場記系統進行實時的場記事件記錄，這些實時記錄的場記信息會極大的方便各體育記者進行關鍵鏡頭的定位，提高新聞和賽事集錦節目的制作效率。那么主分IBC要同步的賽事資料中自然也要包含場記信息。
     3.低碼素材同步
     主分IBC收錄時采用高低碼同步收錄（雙采），收錄后的低碼素材要及時傳輸到另外一個IBC中。
     4.高碼素材同步
     分IBC中收錄的素材要在每天比賽結束后，自動傳輸到主IBC中。主IBC中的高碼素材不需要傳輸到分IBC中。
     5.成品節目回傳
     允許前端記者在分IBC（亞布力）完成成品節目的制作，將打包好的高清成品節目及時回傳到主IBC，實現該節目在主IBC演播室的當日播出。

四.互聯設計方案與關鍵技術
     分析前面提到的五點關鍵技術要求，可以歸納成三種信息同步需求：低碼素材及信息同步、高碼素材回傳、成品節目回傳。在這三類同步需求中，文件傳輸環節是其共同點，也是主分IBC互聯的核心技術所在，所以在關鍵技術介紹部分將對文件傳輸做重點描述。

圖2 分IBC（亞布力）賽事信息、場記信息、低碼素材同步到主IBC（哈爾濱）的過程

     1.低碼素材及信息同步方案
     為了實現賽事信息、場記信息、低碼素材在主分IBC間的同步，設計了如圖2所示的具體方案。圖2詳細描述了賽事信息、場記信息、低碼素材自動從分IBC（亞布力）同步到主IBC（哈爾濱）的過程，具體如下：
     步驟一，收錄編單：相關操作人員在收錄系統中編輯收錄計劃，同時輸入賽事相關信息：參賽隊伍、開始時間、比賽地點等等，這是一個人工操作過程。
     步驟二，賽事信息同步：后端數據同步服務負責自動將賽事信息同步到主IBC。
     步驟三，賽事收錄/場記記錄：比賽開始，收錄視頻服務器按照收錄計劃開始收錄，場記人員開始使用場記系統記錄場記信息。場記記錄是一個人工操作過程。
     步驟四，視頻、場記關聯整理：收錄時間達到預先定義的時間間隔，產生視音頻片段素材，將場記系統記錄的場記信息和這些片段建立關聯。這是一個后臺服務自動處理的過程。
     步驟五，低碼視頻（含場記）同步通知：將包含場記的視頻文件作為一個任務通知給文件傳輸調度服務器，讓文件傳輸調度服務器完成最終傳輸任務的調度。這是一個后臺服務自動處理的過程。
     步驟六，低碼文件傳輸（含場記）：傳輸調度服務將傳輸任務調度給具體的文件傳輸服務，由文件傳輸服務完成具體的傳輸任務。這是一個后臺服務自動處理的過程。
     步驟七，登記低碼視頻和場記信息：文件傳輸到主IBC后，傳輸調度服務會通知主IBC的數據同步服務，告知其文件傳輸完畢，主IBC的數據同步服務此時需要將傳來的文件登記到主IBC信息系統中，同時將場記系統也記錄到主IBC的信息系統中。這是一個后臺服務自動處理的過程。
     步驟八，主IBC檢索使用：用戶在主IBC的賽事檢索系統中可以看到場記信息，同時也可以瀏覽低碼視頻進行編輯創作。該步驟需要人工參與。
     從主IBC向分IBC同步賽事信息、場記信息、低碼流視音頻文件的過程和上面描述的過程非常相似，僅僅是將主分IBC互相換位一下。

     2.高碼素材同步方案
     高碼同步過程相對簡單，這里不再提供流程圖示，而是僅以從分IBC向主IBC同步高碼素材為例描述一下整個過程，具體的系統銜接情況也可以參考圖2。
     步驟一，按策略通知傳輸高碼：首先由分IBC的數據同步服務，按照時間策略向文件傳輸調度服務發送文件傳輸任務。
     步驟二，傳輸高碼流視音頻文件：文件傳輸調度服務收到任務后，將任務下發給空閑的文件傳輸服務，文件傳輸服務完成具體的文件傳輸工作。
     步驟三，高碼文件登記：文件傳輸完畢后，文件傳輸調度服務將會通知主IBC的數據同步服務，主IBC數據同步服務需要把傳輸到主IBC的高碼流視音頻文件登記到主IBC的信息系統中。
     在高碼流同步的整個過程無需人工干預，全部由后臺服務自動完成。
     3.成品節目回傳方案
     從分IBC將成品節目回傳到主IBC的過程和高碼素材回傳的過程相似，其核心也是文件傳輸的過程，具體步驟如下：
     步驟一，發送節目回傳任務：用戶手工挑選打包合成好的成品節目，啟動節目回傳過程。
     步驟二，傳輸成品節目視音頻文件：文件傳輸調度服務收到任務后，將任務下發給空閑的文件傳輸服務，文件傳輸服務完成具體的文件傳輸工作。
     步驟三，成品節目登記：文件傳輸完畢后，文件傳輸調度服務將會通知主IBC的數據同步服務，主IBC數據同步服務需要把傳輸到主IBC的成品節目視音頻文件登記到主IBC的信息系統中，并且要標明這些內容為成品節目。
     整個節目回傳過程除了發起任務外，其他環節無需人工干預。另外，這些回傳的內容都是當天在演播室播出的節目，對時效性要求很高，所以在文件傳輸調度環節要按照最高優先級處理，優先傳輸成品節目。
     4.互聯關鍵技術實現
     在賽事同步方案中最關鍵的問題就是：傳輸效率能否滿足實際需求。從現場實測的主分IBC之間光纜傳輸帶寬（空傳數據，非文件傳輸）看，效果比較理想，基本接近本地千兆以太網的速度。那么剩下的問題就是要讓實際文件傳輸的速度盡可能接近空傳數據速度即可，同時還要保證數據傳輸的準確性。
     我們知道一個典型的TCP傳輸過程如下：
     ·發送端：從文件讀取一段數據到內存（t1），將內存中的數據寫入到Socket（t2），然后再從文件讀取下一段數據。
     ·接收端：從Socket接收一段數據（t3），將數據寫入文件（t4），然后再從Socket接收下一段數據。
     這個過程涉及到所有環節都是采用同步方式，對于某一段數據來說傳輸總的時間至少是t1+max(t2,t3)+t4，如果一個文件有n段數據的話，那么傳輸總時長至少為n×(t1+max(t2,t3)+t4）。采用這種傳輸方式肯定不能充分利用主分IBC間光纜傳輸的帶寬，將時間浪費在本地系統的存儲上。
     為提高傳輸速度，在具體實現時，我們采用多線程+多數據隊列的方式完成整個傳輸過程。發送端和接收端的關鍵邏輯如圖3、圖4所示。

      
            圖3 TCP傳輸數據發送端實現邏輯圖               圖4 TCP傳輸數據接收端實現邏輯圖
     在實際的實現過程中，還加入了MD5校驗線程，從而保證了數據傳輸的可靠性，相應的也會增加一個MD5校驗數據鏈表。因為MD5線程的介入，才決定使用多數據隊列方式，而沒有使用一個統一的公共鏈表，這樣可以最大程度上減少由于線程間數據同步帶來的整體傳輸性能的下降。采用這種模式，文件傳輸的整體耗時應該接近n×max(t1,t2,t3,t4,t5,t6)。注：t5，t6為MD5計算耗時。
     另外，值得一提的是，MD5校驗失敗后，不是終止文件傳輸，而是繼續傳輸，僅僅將校驗失敗的位置記錄下來，當傳輸結束后，重新傳輸這些校驗失敗的數據，而不是整個文件重新傳輸一遍。采用這種技術也極大地提高了傳輸的整體效率。
     在整個文件傳輸過程中還涉及到任務調度、優先級調整等一些技術點，在這里就不再一一贅述了。

五.實際使用效果
     本系統的實際部署情況為：在主分IBC各部署了兩臺文件傳輸服務器，傳輸調度服務器一臺，部署在主IBC（哈爾濱），另外將數據同步服務部署在主分IBC的文件傳輸服務器上，與文件傳輸服務共用一臺服務器。這樣在實際運行時可以保證有4條傳輸鏈路在工作，其中2條用于從主IBC向分IBC傳輸文件，另外2條用于從分IBC向主IBC傳輸文件。
     經過實際測試和正式運行觀察，單條鏈路的速度在15Mb/sec~21Mb/sec之間波動，平均在16.7Mb/sec左右。單條鏈路的傳輸速度基本稍快于本屆大冬會高碼流視音頻采用的壓縮碼率（碼率為120Mb/sec的DNxHD壓縮格式，采用mxf格式封裝），對于采用1.5Mb/sec的MPEG-4低碼率視音頻來說，傳輸更是游刃有余，按照10分鐘分段的低碼流素材大多在10秒之內完成。
     由于傳輸速度超出項目最初的預期，再加上亞布力同時開展的比賽很少超過2個，所以在比賽期間對高碼流素材的傳輸策略做了調整，由當日所有比賽結束后傳輸改為立即傳輸，優先級的順序從高到低依次是：成品節目回傳、低碼流素材傳輸、高碼流素材傳輸，以便保證節目播出需要。調整后，分IBC（亞布力）的大多數高碼流素材，可以在延遲10分鐘之內回傳到主IBC（哈爾濱），大大提高了節目的時效性，同時高碼流素材及時回傳到主IBC，也降低了現場技術人員的工作強度，縮短了系統維護時間。

六.總結
     本屆在哈爾濱舉行的大冬會按照本文介紹的主分IBC互聯方案搭建的互聯系統，也正式服務于本屆盛會。在為期10天的比賽過程中，該互聯系統達到了最初的設計要求，圓滿完成主分IBC之間賽事資料同步任務，贏得了包括世界大學生體育聯合會、第24界世界大冬會組委會以及中央電視臺、黑龍江電視臺、上海文廣新聞傳媒集團、北京電視臺、天津電視臺、大連電視臺等國內外用戶的好評。
     該互聯系統，保障了主、分系統之間的高清異地、實時編輯，實現了賽事資料的即時共享，在遠距離高速數據傳輸方面，為今后廣播電視領域在大型多地舉辦的體育賽事，或者其他大型活動，進行異地聯合報道，實現視音頻以及相關資料的即時共享，積累了寶貴經驗，同時也為其他領域的大數據量遠程異地同步問題，提供了參考。