陳 晉 江蘇廣電總臺電視技術部
江蘇廣電總臺優(yōu)漫卡通衛(wèi)視及國際頻道專用的高清制作網絡,在2016年啟動了電視節(jié)目網絡送播業(yè)務,發(fā)現網絡集群打包服務無法滿足網絡送播業(yè)務需求,提供業(yè)務流程底層支持的WEB服務軟件存在較多問題。
在網絡送播正式啟動前,技術部門運維人員及系統(tǒng)程序員對送播流程中各個環(huán)節(jié)都做了充分的測試,但是測試環(huán)境和實際使用環(huán)境是兩個不同的運行環(huán)境,存在很大的差別。嚴重影響到播出安全的主要問題有3點:
(1)打包服務環(huán)節(jié)任務堆積;
(2)WEB服務軟件設計不合理;
(3)數據庫死鎖現象。
高清制作網在設計建設時,配備了一組集群打包服務,由4臺服務器組成:一臺控制服務器,三臺打包服務器。集群打包的工作流程見圖1。
圖1 集群打包的工作流程
控制服務器的功能是:打包任務接受、故事板切割、任務分發(fā)、素材拼接、素材完整校驗??刂品掌鲗⑺筒ス适掳遄x取,并將打包任務切割為3個部分,交給3臺打包服務器打包,送播故事板打包完成后,對送播素材完整性進行檢驗,通過后向WEB服務提交打包任務完成信息。
在實際的工作中,發(fā)現集群打包表現不如人意。尤其是每天下午2點以后,大量的送播打包任務出現,如果出現有一條打包任務引發(fā)打包服務器出錯,業(yè)務流程中的送播任務都將被卡在打包環(huán)節(jié),因此帶來播出安全隱患。
圖2 串片類故事板及簡單故事板
為了解決業(yè)務流程打包服務環(huán)節(jié)卡任務現象,對集群打包服務與單臺打包服務在實際運用中的打包效率進行測試、對比,發(fā)送了上千條不同時長、不同復雜程度的故事板。測試結果比較結果見圖2、圖3。
串編類故事板及簡單故事板的視頻和字幕軌在6層左右,含少量的視頻特技。復雜故事板及綜藝故事板視頻和字幕軌在10層以上,視頻特技較多。對比集群打包服務與單臺打包服務測試數據得出,標清打包服務時長的閾值在40分鐘,高清打包服務的閾值在30分鐘,隨著打包故事板的時長及復雜程度的增加。集群打包服務的優(yōu)勢越大,反之在短片打包則是單臺打包服務在資源利用上有明顯優(yōu)勢。
圖3 復雜故事板及綜藝節(jié)目故事板
對優(yōu)漫卡通衛(wèi)視及國際頻道節(jié)目的調研發(fā)現,兩個頻道的電視節(jié)目為標清播出,送播故事板的節(jié)目時長95%在45分鐘以內。因此對綜合制作網的打包服務進行調整,將一組集群打包改為4臺獨立打包服務器。如果出現有一條打包任務引發(fā)打包服務器出錯,只會影響送播流程中的單條任務,解決了送播任務在打包環(huán)節(jié)的積壓。
高清制作網配備一主一備二臺WEB服務器。在啟動網絡送播后,出現的很多的問題,大部分都是由WEB服務軟件設計不合理引發(fā)的。
WEB服務是存儲并管理超媒體(包括超文本文件、音頻文件、視頻文件等基于網頁平臺的多媒體文件),且通過網絡把它們傳輸及分配給核心服務器或客戶端的服務器。一般可分成如下4個步驟:連接過程、請求過程、應答過程以及關閉連接。用戶登錄編輯工作站上的全臺認證登錄界面(AUTONET媒資中心),向制作系統(tǒng)發(fā)起操作請求,制作系統(tǒng)根據用戶發(fā)出請求的類型,將任務交給對應的服務器,進而實施任務處理,任務完成以后,將執(zhí)行情況進行反饋,接收到反饋信息WEB服務器和其對應的服務器斷開連接。WEB服務器上述4個步驟環(huán)環(huán)相扣、緊密相聯,邏輯性比較強,可以支持多個進程、多個線程以及多個進程與多個線程相混合的技術, WEB服務的業(yè)務流程見圖4。
圖4 高清制作網WEB服務的業(yè)務流程
高清制作網存在兩種WEB服務容器,TOMCAT及JBOSS,TOMCAT因為在運行時占用的系統(tǒng)資源小,擴展性好,支持負載平衡,TOMCAT主要作用在核心服務之間的數據交互;JBOSS是一個可伸縮的服務器平臺,如果訪問量增加,可以實現多臺服務器同時運算,提高了負載容量,理論上無最大支持在線人數或客戶端的上限。JBOSS主要作用在客戶端與核心服務之間的數據交互。JBOSS與Web服務器在同一個虛擬機中運行,從而大大提高運行效率,提升安全性能。
高清制作網的用戶登錄、任務的發(fā)起、總臺媒資素材導入、媒資素材上傳、節(jié)目送播出等等一系列的任務流程,都是需要WEB服務支持的,WEB服務是整個制作網最重要的服務軟件,同時也是在實際使用過程中修改問題最多的軟件。
圖5 待執(zhí)行任務涌入
圖6 數據庫任務排隊
在送播業(yè)務流程中,WEB服務出現故障,最直接的處理方法就是重啟WEB服務,重啟后WEB服務會釋放掉部分死鎖的任務。當系統(tǒng)流程中存在的業(yè)務不多的情況下,這種處理方法簡單有效,但是流程中的業(yè)務多時,這種方法是無法解決問題的。WEB重啟后,涌入大量待執(zhí)行任務,現象如圖5所示。WEB服務在重啟完成后的瞬間,有大量的待執(zhí)行任務涌入。而為核心服務提供支持的TOMCAT容器,同時發(fā)送的多線程任務數量是一定的,過多的任務出現會使容器溢出,而且客戶端用戶不時有新任務發(fā)起,過多的任務會使WEB服務不穩(wěn)定而關閉。
對數據庫文件進行檢查,發(fā)現有大量的送播出任務在等待執(zhí)行,現象如圖6所示。
(1)調整WEB服務容器設置
對故障出現的現象排查分析發(fā)現,故障出現的原因與系統(tǒng)最初設置的TOMCAT服務同時接受任務進程的數量有關。WEB服務最初設置的TOMCAT容器執(zhí)行多線程任務的數量為180條,超過的任務將被系統(tǒng)拒絕,如果涌入任務過多就會造成WEB服務程序自動關閉。對這個問題最直接的改動就是,增加WEB服務執(zhí)行多線程任務的數量。然而,在實際使用過程中又發(fā)現,多線程任務數量不能設置得過高,超過250條后,整個系統(tǒng)穩(wěn)定性就會下降,經過多次測試發(fā)現系統(tǒng)閾值為250。
(2)數據庫及下游任務執(zhí)行服務調整
WEB是個中間件,負責接受及分配給核心服務器任務,根據任務類型不同將客戶端提出的任務請求分配給不同的服務器執(zhí)行,僅僅增加TOMCAT容器執(zhí)行多線程任務的數量是無用的,還要對下游執(zhí)行服務器,如打包服務、自動技審服務、數據校驗等服務的數據庫軟件都做出相應的調整。這些服務器在執(zhí)行任務過程中出現假死,執(zhí)行信息無法反饋給WEB服務判定,WEB服務仍然按正常流程不斷下發(fā)同一任務及接受客戶端新任務,那么直接后果就是發(fā)生數據庫死鎖。
在出現的問題中,自動技審出現的故障最為典型。WEB服務不斷重發(fā)任務現象如圖7所示。
圖7 WEB服務重發(fā)任務現象
圖8 2條自動技審任務調用同一個資源
自動技審服務器在執(zhí)行任務時發(fā)生錯誤,無法將執(zhí)行信息反饋給WEB服務,造成WEB服務不停地將任務重發(fā),業(yè)務流程無法執(zhí)行新的任務,造成WEB服務任務堆積,因而卡死WEB服務,使WEB服務程序自動關閉。多數情況下,可以認為如果一個資源被鎖定,它總會在以后某個時間被釋放。而死鎖發(fā)生在當多個進程訪問同一數據庫時,其中每個進程擁有的鎖都是其他進程所需的,由此造成每個進程都無法繼續(xù)下去。簡單的說,進程A等待進程B釋放它的資源,B又等待A釋放它的資源,這樣互相等待就形成死鎖,見圖8。
出現這個情況,提交的任務不會消失,會不停的循環(huán)出現,重啟服務后系統(tǒng)會自動釋放這些失敗的任務或直接在數據庫中將死鎖任務刪除。
數據庫死鎖的現象雖然不能完全避免,但可以使死鎖數據數量減至最少。這就需要系統(tǒng)流程中的各個環(huán)節(jié)的服務軟件最優(yōu)化,軟件各部件之間的溝通有效。需要確定服務資源的合理分配,避免進程永久占據系統(tǒng)資源。此外,也要防止進程在處于等待狀態(tài)的情況下占用資源,在系統(tǒng)運行過程中,對進程發(fā)出的每一個任務能夠滿足的資源申請進行動態(tài)檢查,并根據檢查結果決定是否分配資源。若分配后任務可能發(fā)生死鎖,則不予分配,否則予以分配 。因此,對資源的分配要給予合理的規(guī)劃。
在網絡流程設計以及完成的情況下,修改其中一個環(huán)節(jié)是非常困難的,往往修改其中一個問題點會帶來其他服務的調整。在每個環(huán)節(jié)都增加一個檢查程序,對所有在執(zhí)行及等待執(zhí)行自動掃描,若發(fā)現有兩條任務處在相互等待中,就直接判定這兩條任務失敗,將資源釋放出來,只要重發(fā)兩條失敗任務即可,不會影響互聯互通業(yè)務流程整體運行。
(3)定期刪除數據庫中無效的數據
系統(tǒng)在長時間的運行過程中,流程中的各個環(huán)節(jié)出現問題是不可避免的,都可能在數據庫中留下無效的數據,如圖9所示。
圖9 數據庫中無效數據
通過查看數據庫任務時間可以看到,無效數據會長期駐留在數控庫中,擠占系統(tǒng)資源,使數據庫執(zhí)行效率變低,這就需要運維技術員定期對數據庫進行清理。
(4)增加一臺WEB服務器
對WEB 服務軟件進行過多次的修改及測試,單純采用修改軟件程序方式解決,或多或少都存在一些不可避免的BUG,最直接有效的方法是,對WEB服務軟件進行修改,將WEB服務內外服務分離,添加一臺WEB服務器專用與總臺主干互聯互通業(yè)務的交互。這樣做最大的好處就是使WEB服務軟件設計可以針對性的優(yōu)化,分工細化各司其職。
在網絡送播正式啟動前,對送播流程中各個環(huán)節(jié)都做了充分的測試,但是測試環(huán)境和實際使用環(huán)境存在很大的差別,這就造成了送播流程中的很多問題都是在啟動節(jié)目網絡送播后才暴露出來,需要較長時間對網絡送播流程中的各個環(huán)節(jié)做出調整,并且在使用過程中逐步改進。優(yōu)漫卡通衛(wèi)視&國際頻道制作網經過大小改動上百次,于2017年上半年滿足了頻道業(yè)務的需求。