高清播控系統中接口服務器的使用

王師

摘要：本文著重介紹了高清播出網絡中接口服務器的使用，對接口服務器的特點和部署進行了說明，詳細講解了在使用過程接口消息服務可能出現的若干問題和解決辦法。

關鍵詞：消息服務器;分布式系統;MSMQ;C/S結構;高清播出

概述

重慶廣播電視集團（總臺）高清播總控項目由大洋公司進行軟件開發和系統集成。根據實際需求，結合系統地域分散和內外網互聯互通、分布式系統的情況，大洋公司在系統內核保持較少改變的基礎上，通過接口消息系統定制開發，保持軟件系統可靠性和穩定性，滿足我臺需求，達到內外網系統互聯互通。對大洋軟件工程師而言，使用接口消息服務器既做到了滿足客戶需求，精減高效，又達到靈活、穩定、安全、快捷的目的。

在內網播出機房范圍內，為高效安全專用機房環境，使用C/S結構，直接與數據庫進行讀寫操作，直接與消息服務進行通信。在外網環境中，相對比較復雜，使用虛偽專網、B/S結構，通過接口消息服務器傳遞播出系統內各個數據庫內表格的信息更新，滿足播出、編單、上載、節目代碼申請等不同的業務需求。

一.接口服務器介紹

接口服務器作為網絡中的節點，專門用來存儲、轉發相關數據、信息。它是網絡上一種為客戶端計算機提供各種消息類服務的高性能的計算機，它的高性能主要體現在高速度運算能力、可靠性、強大的外部數據吞吐能力等。

為什么會需要消息服務器？

主要原因是由于在高并發、分布式系統中，由于數據來不及實時同步處理，請求往往會發生堵塞，直接導致無數的行鎖表鎖，從而觸發連接錯誤。通過使用消息隊列，我們可以異步處理請求，緩解系統壓力。

根據我臺內外網結構，編播實時互動，地域分散，高安全性的特點，唯有在分布式系統才能滿足需求，這也開創一個國內少有的精編排、布式部署、全高清播總控大系統，滿足13個電視頻道的高清播出。分布式系統部署優缺點：一方面是分布式調用的各模塊高效、獨立，另一方面是系統自身存在的數據庫同步缺陷。無論是何種開發平臺，都因為駐留在不同進程空間的分布式組件，而引入額外的復雜度，并可能對系統的效率、可靠性等諸多方面的負面影響。然而，不可否認的是在應用系統領域，我們總是會面對不同系統之間的通信、集成與整合，尤其當面臨異構系統時，這種分布式的調用與通信變得困難，但它在架構設計中又有不可被取代的獨特的價值。從業務分析與架構質量的角度來講，我們也希望在系統架構中盡可能地形成對服務的重用，通過獨立運行在進程中服務的形式，徹底實現客戶端與服務端的耦合。這常常是架構演化的必然道路。認為可以通過“將獨立的模塊放入獨立的進程”來解決架構因為代碼規模變大而腐化的問題。比如我臺的播出軟件，已經被大洋公司整合進了它的播出架構中，為整個幾十上百個的小系統中的一個，從軟件規模上講，極其腐化，最多只用幾十分之一的代碼。

我們需要一種技術能將在設計時并未考慮互操作的應用集成起來，打破它們之間的隔閡，獲得比單個應用更多的效益。這或許是分布式架構存在的主要意義，這就是消息服務所存在的意義。

消息服務器，是位于應用服務器和數據庫服務器之間的一個服務器。消息隊列服務器作為一個緩沖，接收應用服務器發送過來的數據庫操作命令，然后按照自己的配置，依次發送給對應的不同的服務器來執行。這種數據庫執行的方式，我們稱之為異步寫入數據庫。增加消息隊列服務器有以下幾點好處：

1，由于消息隊列服務器的速度遠遠高于數據庫服務器，所以能夠快速處理并返回數據;

2，消息隊列服務器具有更好的擴展性;

3，在高并發的情況下，延遲寫入數據庫，可以有效降低數據庫的壓力;

凡事都會有利有弊，消息隊列也不例外，所謂知己知彼，百戰不怠。我們要想把消息隊列用的爐火純青，消息隊列的“弊端”也要銘記于心。

由于消息隊列是在寫入消息隊列服務器之后，馬上返回給用戶，此時數據并沒有真正的寫入到數據庫，后續的數據庫操作可能會執行失敗，這顯然是有問題的。我們的做法是通過業務的手段來解決異步帶來的不一致問題。比如我們可以稍微修改一下業務流程，在寫入消息隊列后，不立即返回成功信息，而是等待消息隊列里的進程真正的執行完以后，再通知當前業務成功。如果業務允許，也可在業務上設計重發機制。在我臺，使用的是重發機制。

消息隊列有特殊的應用場景，就是要從中進行取舍，拿出一套權衡利弊之后的解決方案，解決項目中遇到的問題。特別是在新媒體等視音頻業務中磁盤IO的速度與內存的速度差距太大，數據讀寫通常都會成為系統的瓶頸，而升級硬件成本較高，所以通常都會采取軟件的方法來解決這類問題。通常就采用消息隊列的方式來處理。另外，從業務方面來考慮，有些用戶不是很關心的業務，可以從主流程中剝離出來，降低系統的復雜性。隨著電視臺內系統的擴大，系統的復雜性會越來越大，我們都知道，越是復雜的系統，越難維護。消息隊列對解決這種應用場景，也是一個不錯的選擇。各個系統都要調用核心接口，請求核心接口的數據，這種系統，正是通過消息隊列來實現的。消息隊列的使用，可以減少聯調和開發的工作量。

二.接口服務器的部署

安裝消息服務器程序，在所有與消息相關的計算機中配置MicroSoft Message Queue微軟消息隊列，在大洋D3系統配置軟件中的模塊公共配置中，設置消息服務器、消息隊列名和系統隊列名。

如下圖，所有消息日志必須經接口服務器與消息服務器進行通訊，傳遞播出系統內各個數據庫內表格的信息更新，滿足播出、編單、上載、節目代碼申請等不同的業務需求。

消息類別：

1.節目整備類

2.節目上載后播出刷新

3.上載完成后節目整備

4.播出值班員節目單更新

5.廣告審查后頻道編單

三.消息服務的故障和解決方案

所有消息客戶端都是在操作系統MicroSoft Message Queue微軟消息隊列中配置調用，在播出系統中第一次調用大洋軟件時，將SysConfig配置的消息服務器，消息類別與操作系統通訊，調入在線進程中。

播控消息服務工作異常，表現為打開素材播控軟件素材管理器時，顯示“打開消息隊列錯誤”，或者提交一條素材同步，遷移或回遷任務時，任務查看窗口中顯示“未處理”。

節目編單消息服務工作異常，表現為廣告已審核通過的廣告，頻道節目編單顯示為廣告未審核，不能使用。

消息服務器故障分析：

運維工作本身就是“路漫漫其修遠兮 吾將上下而求索”，在今年的5-6月份，連續出現了多次消息服務器的問題，一次比一次嚴重，先是消息服務器有短時堵塞，接著是有時延，最后是完全不通。這個過程讓我們一次又一次加深了對消息服務器的理解，明白了它固有的優勢和劣勢，發現了現有播出系統存在的缺陷和解決之道，也算“塞翁失馬，焉知非?！?，最終收獲滿滿。

通過消息服務器的觀察，常態的消息日志約為幾秒一條，最多的消息處理速度為一秒十條這個數量級，如果消息太多，消息服務器就會有排隊，導致消息處理堵塞，在出現問題時，會發現消息顯示和消息日志記錄的量呈現數量級爆炸式增長，進一步抓包分析，懷疑可能是系統內某臺電腦持續發送消息引起。在消息機制有時延的情況下，退出中止消息服務器工作后，還能正常運行，但在嚴重堵塞時，只有重啟消息服務器，將所有未處理的消息事務全部拋棄才能解決問題。如圖所示，2018年7月8日到12日測試堵塞的情況，MSG_CIIPMGR就非常多的日志記錄，7月13日到16日正常時，MSG_CIIPMGR就很少的日志記錄。如下圖的文本TXT，文件大小可很清楚。

這就是分布式系統中固有的問題，如同蝴蝶效應般，一個小的BUG，通過系統放大，可能影響整個系統安危。我們通過屏蔽禁用軟件的某些功能，防止問題再次出現。處理措施：

1.重新啟動消息服務器上的消息服務

2.重啟消息服務器

3.在SysConfig中修改消息服務器的IP指向為冷備消息服務器。

日常工作中，可以通過不定期的檢查，觀察消息服務器的運行界面，核查屏幕上的顯示記錄，可以在一定程度上判斷是否正常，提前處理。消息服務器的定期重啟也有助于服務器正常運行。

四、總結

經過兩年的使用，我們很好的理解了消息服務器的運行規律，經歷了實戰的風雨，經歷住了時間的考驗，相信在接下來的時間內，我們的運行維護水平會有更進一步的提高。

參考文獻

[1]徐曉東.數字播控系統若干技術問題的分析[J].西部廣播電視，2015（22）

[2]孫國峰.電視臺播出系統的構建分析[J].科技傳播，2014（23）