陳 晉 江蘇廣電總臺電視技術(shù)部

1．引言

江蘇廣電總臺優(yōu)漫卡通衛(wèi)視及國際頻道專用的高清制作網(wǎng)絡(luò)，在2016年啟動了電視節(jié)目網(wǎng)絡(luò)送播業(yè)務，發(fā)現(xiàn)網(wǎng)絡(luò)集群打包服務無法滿足網(wǎng)絡(luò)送播業(yè)務需求，提供業(yè)務流程底層支持的WEB服務軟件存在較多問題。

2. 高清制作網(wǎng)網(wǎng)絡(luò)送播業(yè)務流程中出現(xiàn)的問題

在網(wǎng)絡(luò)送播正式啟動前，技術(shù)部門運維人員及系統(tǒng)程序員對送播流程中各個環(huán)節(jié)都做了充分的測試，但是測試環(huán)境和實際使用環(huán)境是兩個不同的運行環(huán)境，存在很大的差別。嚴重影響到播出安全的主要問題有3點：

（1）打包服務環(huán)節(jié)任務堆積；

（2）WEB服務軟件設(shè)計不合理；

（3）數(shù)據(jù)庫死鎖現(xiàn)象。

3. 打包服務的調(diào)整及優(yōu)化

3.1 集群打包服務業(yè)務流程

高清制作網(wǎng)在設(shè)計建設(shè)時，配備了一組集群打包服務，由4臺服務器組成：一臺控制服務器，三臺打包服務器。集群打包的工作流程見圖1。

圖1 集群打包的工作流程

控制服務器的功能是：打包任務接受、故事板切割、任務分發(fā)、素材拼接、素材完整校驗?？刂品掌鲗⑺筒ス适掳遄x取，并將打包任務切割為3個部分，交給3臺打包服務器打包，送播故事板打包完成后，對送播素材完整性進行檢驗，通過后向WEB服務提交打包任務完成信息。

在實際的工作中，發(fā)現(xiàn)集群打包表現(xiàn)不如人意。尤其是每天下午2點以后，大量的送播打包任務出現(xiàn)，如果出現(xiàn)有一條打包任務引發(fā)打包服務器出錯，業(yè)務流程中的送播任務都將被卡在打包環(huán)節(jié)，因此帶來播出安全隱患。

3.2 集群打包服務與單臺打包服務的比較

圖2 串片類故事板及簡單故事板

為了解決業(yè)務流程打包服務環(huán)節(jié)卡任務現(xiàn)象，對集群打包服務與單臺打包服務在實際運用中的打包效率進行測試、對比，發(fā)送了上千條不同時長、不同復雜程度的故事板。測試結(jié)果比較結(jié)果見圖2、圖3。

串編類故事板及簡單故事板的視頻和字幕軌在6層左右，含少量的視頻特技。復雜故事板及綜藝故事板視頻和字幕軌在10層以上，視頻特技較多。對比集群打包服務與單臺打包服務測試數(shù)據(jù)得出，標清打包服務時長的閾值在40分鐘，高清打包服務的閾值在30分鐘，隨著打包故事板的時長及復雜程度的增加。集群打包服務的優(yōu)勢越大，反之在短片打包則是單臺打包服務在資源利用上有明顯優(yōu)勢。

3.3 打包服務的優(yōu)化

圖3 復雜故事板及綜藝節(jié)目故事板

對優(yōu)漫卡通衛(wèi)視及國際頻道節(jié)目的調(diào)研發(fā)現(xiàn)，兩個頻道的電視節(jié)目為標清播出，送播故事板的節(jié)目時長95%在45分鐘以內(nèi)。因此對綜合制作網(wǎng)的打包服務進行調(diào)整，將一組集群打包改為4臺獨立打包服務器。如果出現(xiàn)有一條打包任務引發(fā)打包服務器出錯，只會影響送播流程中的單條任務，解決了送播任務在打包環(huán)節(jié)的積壓。

4. WEB服務及數(shù)據(jù)庫服務的優(yōu)化

高清制作網(wǎng)配備一主一備二臺WEB服務器。在啟動網(wǎng)絡(luò)送播后，出現(xiàn)的很多的問題，大部分都是由WEB服務軟件設(shè)計不合理引發(fā)的。

4.1 高清制作網(wǎng)WEB服務流程

WEB服務是存儲并管理超媒體（包括超文本文件、音頻文件、視頻文件等基于網(wǎng)頁平臺的多媒體文件），且通過網(wǎng)絡(luò)把它們傳輸及分配給核心服務器或客戶端的服務器。一般可分成如下4個步驟：連接過程、請求過程、應答過程以及關(guān)閉連接。用戶登錄編輯工作站上的全臺認證登錄界面（AUTONET媒資中心），向制作系統(tǒng)發(fā)起操作請求，制作系統(tǒng)根據(jù)用戶發(fā)出請求的類型，將任務交給對應的服務器，進而實施任務處理，任務完成以后，將執(zhí)行情況進行反饋，接收到反饋信息WEB服務器和其對應的服務器斷開連接。WEB服務器上述4個步驟環(huán)環(huán)相扣、緊密相聯(lián)，邏輯性比較強，可以支持多個進程、多個線程以及多個進程與多個線程相混合的技術(shù)， WEB服務的業(yè)務流程見圖4。

圖4 高清制作網(wǎng)WEB服務的業(yè)務流程

高清制作網(wǎng)存在兩種WEB服務容器，TOMCAT及JBOSS，TOMCAT因為在運行時占用的系統(tǒng)資源小，擴展性好，支持負載平衡，TOMCAT主要作用在核心服務之間的數(shù)據(jù)交互；JBOSS是一個可伸縮的服務器平臺，如果訪問量增加，可以實現(xiàn)多臺服務器同時運算，提高了負載容量，理論上無最大支持在線人數(shù)或客戶端的上限。JBOSS主要作用在客戶端與核心服務之間的數(shù)據(jù)交互。JBOSS與Web服務器在同一個虛擬機中運行，從而大大提高運行效率，提升安全性能。

高清制作網(wǎng)的用戶登錄、任務的發(fā)起、總臺媒資素材導入、媒資素材上傳、節(jié)目送播出等等一系列的任務流程，都是需要WEB服務支持的，WEB服務是整個制作網(wǎng)最重要的服務軟件，同時也是在實際使用過程中修改問題最多的軟件。

4.2 WEB服務出現(xiàn)的問題

圖5 待執(zhí)行任務涌入

圖6 數(shù)據(jù)庫任務排隊

在送播業(yè)務流程中，WEB服務出現(xiàn)故障，最直接的處理方法就是重啟WEB服務，重啟后WEB服務會釋放掉部分死鎖的任務。當系統(tǒng)流程中存在的業(yè)務不多的情況下，這種處理方法簡單有效，但是流程中的業(yè)務多時，這種方法是無法解決問題的。WEB重啟后，涌入大量待執(zhí)行任務，現(xiàn)象如圖5所示。WEB服務在重啟完成后的瞬間，有大量的待執(zhí)行任務涌入。而為核心服務提供支持的TOMCAT容器，同時發(fā)送的多線程任務數(shù)量是一定的，過多的任務出現(xiàn)會使容器溢出，而且客戶端用戶不時有新任務發(fā)起，過多的任務會使WEB服務不穩(wěn)定而關(guān)閉。

對數(shù)據(jù)庫文件進行檢查，發(fā)現(xiàn)有大量的送播出任務在等待執(zhí)行，現(xiàn)象如圖6所示。

4.3 對WEB服務的調(diào)整

（1）調(diào)整WEB服務容器設(shè)置

對故障出現(xiàn)的現(xiàn)象排查分析發(fā)現(xiàn)，故障出現(xiàn)的原因與系統(tǒng)最初設(shè)置的TOMCAT服務同時接受任務進程的數(shù)量有關(guān)。WEB服務最初設(shè)置的TOMCAT容器執(zhí)行多線程任務的數(shù)量為180條，超過的任務將被系統(tǒng)拒絕，如果涌入任務過多就會造成WEB服務程序自動關(guān)閉。對這個問題最直接的改動就是，增加WEB服務執(zhí)行多線程任務的數(shù)量。然而，在實際使用過程中又發(fā)現(xiàn)，多線程任務數(shù)量不能設(shè)置得過高，超過250條后，整個系統(tǒng)穩(wěn)定性就會下降，經(jīng)過多次測試發(fā)現(xiàn)系統(tǒng)閾值為250。

（2）數(shù)據(jù)庫及下游任務執(zhí)行服務調(diào)整

WEB是個中間件，負責接受及分配給核心服務器任務，根據(jù)任務類型不同將客戶端提出的任務請求分配給不同的服務器執(zhí)行，僅僅增加TOMCAT容器執(zhí)行多線程任務的數(shù)量是無用的，還要對下游執(zhí)行服務器，如打包服務、自動技審服務、數(shù)據(jù)校驗等服務的數(shù)據(jù)庫軟件都做出相應的調(diào)整。這些服務器在執(zhí)行任務過程中出現(xiàn)假死，執(zhí)行信息無法反饋給WEB服務判定，WEB服務仍然按正常流程不斷下發(fā)同一任務及接受客戶端新任務，那么直接后果就是發(fā)生數(shù)據(jù)庫死鎖。

在出現(xiàn)的問題中，自動技審出現(xiàn)的故障最為典型。WEB服務不斷重發(fā)任務現(xiàn)象如圖7所示。

圖7 WEB服務重發(fā)任務現(xiàn)象

圖8 2條自動技審任務調(diào)用同一個資源

自動技審服務器在執(zhí)行任務時發(fā)生錯誤，無法將執(zhí)行信息反饋給WEB服務，造成WEB服務不停地將任務重發(fā)，業(yè)務流程無法執(zhí)行新的任務，造成WEB服務任務堆積，因而卡死WEB服務，使WEB服務程序自動關(guān)閉。多數(shù)情況下，可以認為如果一個資源被鎖定，它總會在以后某個時間被釋放。而死鎖發(fā)生在當多個進程訪問同一數(shù)據(jù)庫時，其中每個進程擁有的鎖都是其他進程所需的，由此造成每個進程都無法繼續(xù)下去。簡單的說，進程A等待進程B釋放它的資源，B又等待A釋放它的資源，這樣互相等待就形成死鎖，見圖8。

出現(xiàn)這個情況，提交的任務不會消失，會不停的循環(huán)出現(xiàn)，重啟服務后系統(tǒng)會自動釋放這些失敗的任務或直接在數(shù)據(jù)庫中將死鎖任務刪除。

數(shù)據(jù)庫死鎖的現(xiàn)象雖然不能完全避免，但可以使死鎖數(shù)據(jù)數(shù)量減至最少。這就需要系統(tǒng)流程中的各個環(huán)節(jié)的服務軟件最優(yōu)化，軟件各部件之間的溝通有效。需要確定服務資源的合理分配，避免進程永久占據(jù)系統(tǒng)資源。此外，也要防止進程在處于等待狀態(tài)的情況下占用資源，在系統(tǒng)運行過程中，對進程發(fā)出的每一個任務能夠滿足的資源申請進行動態(tài)檢查，并根據(jù)檢查結(jié)果決定是否分配資源。若分配后任務可能發(fā)生死鎖，則不予分配，否則予以分配 。因此，對資源的分配要給予合理的規(guī)劃。

在網(wǎng)絡(luò)流程設(shè)計以及完成的情況下，修改其中一個環(huán)節(jié)是非常困難的，往往修改其中一個問題點會帶來其他服務的調(diào)整。在每個環(huán)節(jié)都增加一個檢查程序，對所有在執(zhí)行及等待執(zhí)行自動掃描，若發(fā)現(xiàn)有兩條任務處在相互等待中，就直接判定這兩條任務失敗，將資源釋放出來，只要重發(fā)兩條失敗任務即可，不會影響互聯(lián)互通業(yè)務流程整體運行。

（3）定期刪除數(shù)據(jù)庫中無效的數(shù)據(jù)

系統(tǒng)在長時間的運行過程中，流程中的各個環(huán)節(jié)出現(xiàn)問題是不可避免的，都可能在數(shù)據(jù)庫中留下無效的數(shù)據(jù)，如圖9所示。

圖9 數(shù)據(jù)庫中無效數(shù)據(jù)

通過查看數(shù)據(jù)庫任務時間可以看到，無效數(shù)據(jù)會長期駐留在數(shù)控庫中，擠占系統(tǒng)資源，使數(shù)據(jù)庫執(zhí)行效率變低，這就需要運維技術(shù)員定期對數(shù)據(jù)庫進行清理。

（4）增加一臺WEB服務器

對WEB 服務軟件進行過多次的修改及測試，單純采用修改軟件程序方式解決，或多或少都存在一些不可避免的BUG，最直接有效的方法是，對WEB服務軟件進行修改，將WEB服務內(nèi)外服務分離，添加一臺WEB服務器專用與總臺主干互聯(lián)互通業(yè)務的交互。這樣做最大的好處就是使WEB服務軟件設(shè)計可以針對性的優(yōu)化，分工細化各司其職。

5. 結(jié)束語

在網(wǎng)絡(luò)送播正式啟動前，對送播流程中各個環(huán)節(jié)都做了充分的測試，但是測試環(huán)境和實際使用環(huán)境存在很大的差別，這就造成了送播流程中的很多問題都是在啟動節(jié)目網(wǎng)絡(luò)送播后才暴露出來，需要較長時間對網(wǎng)絡(luò)送播流程中的各個環(huán)節(jié)做出調(diào)整，并且在使用過程中逐步改進。優(yōu)漫卡通衛(wèi)視&國際頻道制作網(wǎng)經(jīng)過大小改動上百次，于2017年上半年滿足了頻道業(yè)務的需求。