葛 曉 燕

(商丘學院體育學院 河南 商丘 476000)

0 引 言

近年來，我國體育直播產(chǎn)業(yè)呈現(xiàn)井噴式發(fā)展，騰訊體育、PP體育和直播吧等各大在線體育平臺均購買大量體育賽事直播版權(quán)，如以世界杯、田徑錦標賽為代表的杯賽賽事和以NBA、英超、法網(wǎng)、澳網(wǎng)為代表的常規(guī)賽事。我國體育賽事直播朝著正規(guī)化、規(guī)?；l(fā)展。相比傳統(tǒng)電視平臺，網(wǎng)絡直播不僅可以提供更個性和豐富的體育直播服務，還擴展了體育賽事直播產(chǎn)業(yè)的商業(yè)模式，包括付費觀看、版權(quán)分銷、會員訂購和視頻廣告等，從而進一步推動了體育網(wǎng)絡直播行業(yè)朝著健康、規(guī)模化和產(chǎn)業(yè)化的道路發(fā)展。

僅2018年4月份，國內(nèi)體育類直播APP活躍用戶就有4 643.5萬人，全年體育直播播放量超過5.5億次。體育直播的核心是賽事內(nèi)容，熱門賽事和常規(guī)賽事的播放量和用戶基數(shù)均有較大差異。這對各大直播平臺流數(shù)據(jù)檢索能力提出了較高的要求，也直接關(guān)系到平臺是否可以為用戶提供高清、流暢、同步的體育賽事直播服務。目前，盡管基于內(nèi)容的多媒體數(shù)據(jù)檢索受到廣泛的關(guān)注，但仍然面臨諸多挑戰(zhàn)[1]。首先，內(nèi)容本身是主觀存在的，比如視頻文件都是作為單個主體存儲于服務器中，那么就需要一套強大的搜索工具，可以從多方面(包括關(guān)鍵詞、聲音、顏色甚至空間信息)對請求的內(nèi)容進行搜索。其次，如果一種方法或者處理技術(shù)只為一種特定類型的數(shù)據(jù)或者特征而設計和開發(fā)的，那么它通常不適用于其他類型的數(shù)據(jù)或者特征。例如，用于音頻數(shù)據(jù)的技術(shù)可能不適用于處理視頻流量。最后，通常需要徹底搜索多媒體數(shù)據(jù)庫才能夠找到用戶所請求的內(nèi)容，這個過程極其耗時[2]。

目前，視頻流量是網(wǎng)絡負載的主要內(nèi)容。網(wǎng)絡技術(shù)快速發(fā)展，出現(xiàn)了諸多服務啟用技術(shù)，如異步傳輸模式(Asynchronous Transmission Mode,ATM)和非對稱數(shù)字用戶線(Asymmetric Digital Subscriber Line,ADSL)，這也促成了網(wǎng)絡中和視頻需求高度相關(guān)的一項重要服務，即視頻點播(Video On Demand,VOD)業(yè)務[3]。VOD業(yè)務的一個關(guān)鍵挑戰(zhàn)在于需要存儲大量的視頻文件，同時能夠根據(jù)用戶請求，實時地訪問每個視頻文件，并將其通過網(wǎng)絡傳輸給用戶。通常，大量的視頻文件會被存儲在服務器集群上。對于支持VOD服務的計算機集群，我們將其統(tǒng)稱為VOD系統(tǒng)。實際上，VOD系統(tǒng)也可以由單服務器實現(xiàn)，但是單服務器系統(tǒng)的缺陷比較明顯，無法實現(xiàn)系統(tǒng)的彈性擴展和有效的負載均衡。另外，實踐經(jīng)驗表明，多服務器體系結(jié)構(gòu)能夠更加有效地滿足客戶對視頻質(zhì)量的要求，并同時接納更多的視頻請求，這點是單服務器系統(tǒng)所無法保障的[4]。

鑒于以上因素，VOD系統(tǒng)一般被描述為一個均勻分布的服務器集群(包括同構(gòu)和異構(gòu)計算與存儲節(jié)點)。針對現(xiàn)有的VOD系統(tǒng)，已經(jīng)出現(xiàn)了大量的研究工作。這些研究工作所涉及的范圍包括數(shù)據(jù)放置[5]、資源管理[6]、磁盤調(diào)度[7]、訪問控制[8]、同步[9]以及容錯[10]等問題。除此之外，對于服務器集群的負載均衡問題也有諸多研究。然而，這些研究要么只針對一般任務(并非視頻任務)在集群上的負載均衡[11-12]，要么通過探討數(shù)據(jù)放置策略來實現(xiàn)服務器之間的負載均衡[7-8]。一方面，視頻任務和一般任務之間的特征完全不同，針對二者的負載均衡策略無法實現(xiàn)通用。另一方面，數(shù)據(jù)放置策略屬于一種靜態(tài)處理方式，在面對動態(tài)視頻流量請求時，并不能進行有效應對。例如：文獻[10]提出了一種數(shù)據(jù)放置策略，它通過剝離磁盤或者服務器上的視頻對象來避免負載均衡。但是這種方法會產(chǎn)生額外的開銷用于同步不同介質(zhì)上的視頻內(nèi)容，而且它需要使用同構(gòu)的磁盤或者服務器來構(gòu)建VOD系統(tǒng)的想法不切實際。文獻[12]則提出通過在服務器之間復制流行的視頻文件來實現(xiàn)負載均衡，但同樣也面臨著一些問題，比如它需要額外的空間和時間去決定執(zhí)行視頻復制的時間點。此外，其他一些研究人員也研究了分布式VOD系統(tǒng)中的負載均衡問題[7-12]。

本文以集中式的VOD服務器集群為出發(fā)點，研究VOD服務器集群的動態(tài)負載均衡問題。在設計VOD系統(tǒng)框架和算法時，充分考慮服務器集群可能面對的各種負載情況(如I/O密集型或者內(nèi)存密集型負載情況)，同時引入貪心策略，對不同的情形做出不同的決策。例如，對于I/O密集型負載請求，本文算法首先需要滿足該請求對于其他因素(如內(nèi)存和計算)的最低需求，在此基礎上，最大化其所請求的I/O資源。這種設計模式充分考慮了當前請求對于不同資源的需求之間的優(yōu)先級差異，從而最大化業(yè)務請求的效率。

1 系統(tǒng)框架模型

本文提出的VOD系統(tǒng)框架模型如圖1所示。該系統(tǒng)集群中所有的服務器都通過高速網(wǎng)絡(包括ATM交換機、快速以太網(wǎng)或者交叉交換機)連接，從而形成一套內(nèi)部網(wǎng)絡。

圖1 VOD系統(tǒng)模型

盡管每個服務器都具有CPU、內(nèi)存和I/O子系統(tǒng)，但它們所執(zhí)行的功能可能會有所不同，從而一定程度上實現(xiàn)系統(tǒng)的可伸縮性。例如：當用戶發(fā)出視頻對象請求時，首先加載調(diào)度程序的服務器將會對該請求進行內(nèi)容篩選，再根據(jù)請求內(nèi)容通過內(nèi)部網(wǎng)絡搜索視頻文件的位置，最后將該請求與請求的視頻對象一起傳輸給目標服務器。目標服務器接收到請求之后，就會通過外部網(wǎng)絡以給定的速率將視頻文件發(fā)送給該請求的用戶，直至視頻文件傳輸完畢。以上過程依賴于兩項條件，一是由于視頻存儲要求，VOD系統(tǒng)通常需要和磁盤綁定在一起，二是從視頻服務器到用戶之間的網(wǎng)絡帶寬需要得到保障，從而支持大規(guī)模甚至超大規(guī)模視頻流的傳輸。

此外，對于每個視頻服務器，都存在一個等待隊列，用于緩存到達的視頻請求。隊列模型也展示在圖1中，那么可以依據(jù)現(xiàn)有的單隊列模型對VOD系統(tǒng)進行建模。假設VOD系統(tǒng)中的服務器集群通過互聯(lián)網(wǎng)與外部進行通信，從而為視頻請求的到達和服務器的響應提供雙向通道。另外，假設請求的到達速率恒定，且服從泊松分布。組成集群的服務器節(jié)點本質(zhì)上是異構(gòu)的，因此，這些服務器的響應和服務速率會有所區(qū)別，分別用{s1,s2,…,sn}表示。那么，用戶先通過互聯(lián)網(wǎng)以恒定的速率向VOD調(diào)度程序發(fā)送視頻請求。然后，調(diào)度器按照特定的負載均衡策略將這些請求分配給各個視頻服務器節(jié)點。最后，這些服務器節(jié)點以不同的響應速率通過外部網(wǎng)絡將視頻結(jié)果反饋給用戶。

2 負載均衡算法設計

對于到達的每一個視頻請求，通常來說，其對于系統(tǒng)CPU的需求最低，因為視頻請求任務的完成本質(zhì)上是獲取視頻內(nèi)容，但是這個過程需要系統(tǒng)內(nèi)部進行交互，從而需要消耗大量的I/O和內(nèi)存資源。然而，作為VOD服務器集群，我們需要考慮可能會出現(xiàn)各種工作負載情況，包括I/O密集型和內(nèi)存密集型負載。針對這些情形，我們提出了一種適用于各種工作負載條件的負載均衡算法(Load Balancing Algorithm，LBA)。算法會根據(jù)視頻服務器的內(nèi)存、CPU以及任務的I/O需求來平衡整個服務器集群所接收到的視頻請求，進而最小化每個任務的響應時間和完成時間。需要注意的是，這里并不考慮任何任務遷移的情況。

為了實現(xiàn)最小化任務響應和完成時間的目標，需要指明任務的生命周期T。假設任務請求到達的時間點為tarrive，而視頻文件成功全部發(fā)送至用戶端的時間點為tend，那么：

T=tend-tarrive

(1)

這也就意味著從系統(tǒng)接收到請求至系統(tǒng)滿足該請求之間的持續(xù)時間即為任務的生命周期。由于請求的內(nèi)容通常以視頻數(shù)量為單位，那么在T內(nèi)，VOD系統(tǒng)還需要實現(xiàn)從輔助存儲設備加載該視頻文件以及路由和傳輸該視頻文件的過程。

VOD服務器集群負載均衡算法流程如算法1所示。

算法1VOD服務器集群負載均衡算法

輸入：視頻任務請求序列{1,2,3,…,n}

輸出：視頻文件

1. 選擇當前的視頻請求i；

2. FOR(i

3. 計算該任務對于I/O、CPU以及內(nèi)存的需求，表示為I/O(i)、Memory(i)和CPU(i)；

4. 根據(jù)MaxReq(i)=max{I/O(i), Memory(i),CPU(i)}計算最大的資源需求；

5. IF(I/O(i)==MaxReq(i)) DO

6. 計算所有具有較大有效I/O資源(高于所需要的量)，且能夠滿足基本內(nèi)存和CPU需求的服務器節(jié)點；

7. 將任務i分配給這些節(jié)點中能夠以最快速度響應該任務的服務器節(jié)點；

8. ELSE IF(Memory(i)==MaxReq(i)) DO

9. 計算所有具有較大有效內(nèi)存資源(高于所需要的量)，并且能夠滿足基本I/O和CPU需求的服務器節(jié)點；

10. 將任務i分配給這些節(jié)點中能夠以最快速度響應該任務的服務器節(jié)點；

11. ELSE IF(CPU(i)==MaxReq(i)) DO

12. 計算所有具有較大有效CPU資源(高于所需要的量)，并且能夠滿足基本I/O和內(nèi)存需求的服務器節(jié)點；

13. 將任務i分配給這些節(jié)點中能夠以最快速度響應該任務的服務器節(jié)點；

14. END IF

15. 更新該服務器節(jié)點的狀態(tài)；

16. END FOR

算法1用于協(xié)調(diào)跨n個異構(gòu)服務器調(diào)度視頻請求任務。每個服務器對應具體賽事資源。分配方法取決于當前服務器運營所有賽事轉(zhuǎn)播情況，根據(jù)需求分配。接下來，我們將介紹如何對I/O、CPU以及內(nèi)存資源負載進行索引。首先，給定某個服務器節(jié)點，可以通過該節(jié)點當前的CPU負載以及CPU隊列的等待長度為特征，可以確定該節(jié)點是否存在CPU過載的情況。其次，服務器節(jié)點的內(nèi)存負載情況也可以通過該節(jié)點上運行的所有任務所占用的內(nèi)存空間總和來進行判斷。而I/O負載度量則包括兩種類型的I/O訪問，分別為隱式I/O請求和顯式I/O請求，前者由內(nèi)存錯誤導致，而后者通常由任務本身特征導致。

對于算法1中所展示的偽代碼，其輸入為一組提交給負載均衡調(diào)度器的獨立任務。算法本身通過將每個任務按需地分配給獨立的視頻服務器，從而在最小的響應時間內(nèi)，滿足用戶請求，完成請求視頻內(nèi)容的傳輸，并最終實現(xiàn)VOD集群資源的負載平衡。具體而言，步驟1-步驟3完成請求的到達處理，并預估其CPU、I/O和內(nèi)存資源需求，具體操作由負載均衡調(diào)度器完成。步驟4計算出三種資源中需求最大的一項，然后將結(jié)果交付給接下來的計算過程。步驟5-步驟13分別通過和最大值進行比較，判斷出當前任務的類型，從而實現(xiàn)相應的處理。步驟6-步驟7完成對I/O需求最大任務的處理，步驟9-步驟10完成對內(nèi)存需求最大任務的處理，步驟12-步驟13完成對CPU資源需求最大任務的處理。處理的過程中需要遵守兩個約束條件：1) 除了盡量最大化需求量最大的資源外，還需要保證另外兩種資源的有效容量必須滿足最低要求；2) 盡量最小化服務器節(jié)點對于任務的響應時間。根據(jù)以上條件，負載均衡調(diào)度器才能將任務分配給最合適的服務器節(jié)點，從而保證該任務的圓滿完成。

3 實驗與分析

本文采用VOD系統(tǒng)對體育賽事直播網(wǎng)站提供服務。VOD系統(tǒng)由一組服務器節(jié)點所組成，在其中選擇一個節(jié)點，將其定義為視頻請求的主節(jié)點，也稱為集群中的頭節(jié)點，主要負責負載平衡和監(jiān)控其他節(jié)點的可用資源。頭節(jié)點以先到先服務(First Come First Serve,FCFS)的方式處理所有任務，集群中的其他計算節(jié)點則依賴于頭節(jié)點所提供的信息來進行任務分配決策。待執(zhí)行的任務首先到達頭節(jié)點，且假設任務的到達速率是恒定的，那么經(jīng)過頭節(jié)點決策，任務會被分配到最適合的服務器節(jié)點上的本地隊列中等待被執(zhí)行。

3.1 系統(tǒng)性能分析

圖2給出了本文系統(tǒng)框架的性能評估。給定1 000個視頻請求任務，通過增加服務器的數(shù)量來計算總共的任務執(zhí)行時間?？梢钥闯觯S著服務器數(shù)量的不斷增加，1 000個任務的總執(zhí)行時間逐漸減少。因為服務器總數(shù)量的增加導致平均分配給每個服務器的任務數(shù)量的減少，并且由于單個服務器之間為并行工作模式，那么自然就會降低總的執(zhí)行時間。除此之外，還可以觀察到在服務器數(shù)量超過15之后，執(zhí)行時間趨于平穩(wěn)，這表示有效資源數(shù)量已經(jīng)超過任務的數(shù)量，任務的完成度趨于飽和。通過多次重復性的測試，將服務器數(shù)量從1變化至20，系統(tǒng)在18～19臺服務器上達到了飽和點，即執(zhí)行時間不再提高，這也從一定程度上反映出了本文提出的VOD系統(tǒng)框架模型的合理性。

圖2 提出系統(tǒng)模型的性能圖

3.2 對比分析

為了驗證提出算法的有效性，將LBA與FCFS、隨機策略(Random)進行比較。其中，F(xiàn)CFS按照到達順序?qū)⑷蝿辗峙浣o節(jié)點，如任務1分配給節(jié)點1、任務2分配給節(jié)點2等。隨機策略則將任務隨機分配給集群中的任一節(jié)點。對于這三種算法，我們探討了在任務到達速率不變情況下的服務器負載均衡情況。為了便于觀察結(jié)果，我們計算了不同數(shù)量的任務條件下，服務器集群負載的標準偏差值。通常來說，這個值越接近于0，服務器集群內(nèi)部的負載越均衡。那么對于具有n個異構(gòu)服務器的集群，其標準差的定義如下：

(2)

式中：ci為節(jié)點的能力值；pi為按比例計算的任務的累積概率。給定20臺服務器，改變?nèi)蝿盏臄?shù)量(從1 000至2 500)，實驗結(jié)果如圖3和表1所示。

圖3 三種算法的負載均衡標準差比較

表1 服務器負載均衡標準差比較(給定20臺服務器)

圖3主要用于對比不同算法之間的優(yōu)劣勢，而通過表1則能夠準確知道不同算法所取得的標準差的值。由圖3可知，相較于FCFS和Random算法，使用LBA算法能夠更加好地平衡集群內(nèi)部的各服務器節(jié)點之間負載情況。除此之外，隨著進入系統(tǒng)任務數(shù)量的不斷增加，服務器的負載情況也會相應惡化。這是因為總數(shù)量的增多必然會導致分配到各服務器的任務數(shù)量差異越來越明顯。盡管如此，LBA可以針對不同特征的視頻請求任務，采用不同的分配方式，相對而言更加合理，更能夠適應系統(tǒng)的彈性擴展需求。

3.3 應用驗證與評估

為了在實際環(huán)境中進一步驗證提出算法的優(yōu)勢，本文引入了騰訊云平臺，通過在其上部署提出的算法，來實現(xiàn)用戶與體育直播視頻之間的負載均衡。以2019年4月16號的NBA直播比賽(勇士-快船)為例，將視頻文件存儲在騰訊云中，測試直播期間平臺所能夠接入的最大用戶數(shù)量和平均直播帶寬，結(jié)果如表2所示。

表2 負載均衡算法在實際應用中的驗證比較

可以看出，本文算法在直播期間能夠接入的用戶數(shù)量最多，這是因為提出的算法充分考慮了視頻服務器之間的負載均衡。相較于與對比算法，其資源利用最高，因此，給定相同的資源，本文算法能夠接納更多的用戶。除此之外，三種算法平均分配給每個用戶的直播帶寬相差不大，這是因為直播內(nèi)容的傳輸需要經(jīng)過互聯(lián)網(wǎng)，互聯(lián)網(wǎng)上的帶寬分配和用戶的付費模式有關(guān)。用戶訂購且用于體育直播的帶寬上限為0.5 Mbit/s，觀察表2可以發(fā)現(xiàn)，本文算法能夠交付最接近于上限值的平均直播帶寬(0.48 Mbit/s)。主要原因在于系統(tǒng)內(nèi)部進行負載均衡，直播內(nèi)容傳輸出系統(tǒng)的速率相對對比算法較高，因此導致了這三種算法之間不同的平均直播帶寬。

4 結(jié) 語

本文針對體育賽事直播平臺中的VOD集群所面臨的各種負載情況提出了一種負載均衡算法LBA，針對不同特征的請求，為其計算和分配符合其特征的服務器節(jié)點。該算法的目標是在VOD集群中實現(xiàn)全局磁盤資源利用率的最大化，同時最大限度地減少在VOD集群上運行的作業(yè)的響應和執(zhí)行時間。通過與FCFS和Random算法進行試驗對比，發(fā)現(xiàn)本文算法能夠獲得更好的負載均衡結(jié)果，極大地提高了體育網(wǎng)絡直播平臺負載均衡能力，可以高效地為用戶提供一個流暢、高清的網(wǎng)絡直播服務。