面向大規(guī)模網(wǎng)絡的實時高可靠消息分發(fā)技術

劉飛揚， 葉 麟， 余翔湛， 趙俊達

(哈爾濱工業(yè)大學 計算機科學與技術學院， 哈爾濱 150001)

0 引 言

如今，高速發(fā)展的互聯(lián)網(wǎng)已經(jīng)成為生活中不可或缺的一部分，如何實現(xiàn)大規(guī)模、實時和高可靠的數(shù)據(jù)傳輸一直是互聯(lián)網(wǎng)研究的熱門方向。在互聯(lián)網(wǎng)出現(xiàn)伊始，由于數(shù)據(jù)量都比較小，大規(guī)模的數(shù)據(jù)分發(fā)不會產(chǎn)生太大的時間與資源消耗。但是隨著流媒體的不斷發(fā)展和網(wǎng)絡用戶的不斷增加，藍光視頻、軟件更新和在線視頻流等的分發(fā)越來越需要更多的網(wǎng)絡資源，基于內容的服務和應用呈現(xiàn)指數(shù)增長。據(jù)估計，視頻流量將占所有消費者互聯(lián)網(wǎng)流量的82%(2021年)[1]。而網(wǎng)絡內容分發(fā)需要提供較低的延遲、快速的傳輸速度和服務的可靠性。學術界提出了內容分發(fā)網(wǎng)絡[2](Content Delivery Network, CDN)和點對點通信[3](Peer-to-Peer, P2P)的相關概念。

內容分發(fā)網(wǎng)絡是一個通過策略部署在不同網(wǎng)絡與區(qū)域的內容分發(fā)整體系統(tǒng)，可通過增加緩存服務器來提高服務質量。緩存服務器通常位于網(wǎng)絡的邊緣，離用戶僅有幾跳路由的距離。即內容分發(fā)網(wǎng)絡架設有源服務器與區(qū)域緩存服務器，在用戶請求資源時，將請求重定向至距離用戶最近的區(qū)域緩存服務器，使用戶可以就近取得所需的內容，提高用戶訪問網(wǎng)站的響應速度。同時，區(qū)域緩存服務器是內容提供商(Internet Content Provider, ICP) 源服務器的一個緩存鏡像。這樣，內容持有者通過內容分發(fā)網(wǎng)絡服務提供商傳播內容，向用戶提供優(yōu)質的服務。

點對點通信網(wǎng)絡是一個節(jié)點分布在互聯(lián)網(wǎng)各個角落的內容共享網(wǎng)絡，并通過成員之間的內容共享來提供服務。在點對點通信網(wǎng)絡的架構中，每一個節(jié)點同時扮演服務器和客戶端兩種角色，因此就既是內容請求者、又是內容提供者，還能其它節(jié)點通過相互合作來交換內容。點對點通信網(wǎng)絡中的節(jié)點都是自愿加入的，可以隨時加入和離開網(wǎng)絡。這使得越來越多的人自愿地加入點對點通信網(wǎng)絡。點對點通信網(wǎng)絡中的節(jié)點越多，整個網(wǎng)絡的分發(fā)性能就越強。點對點通信網(wǎng)絡具有較高的可擴展性、容錯性、魯棒性，適合內容共享網(wǎng)絡的部署。

綜上所述，在內容分發(fā)網(wǎng)絡的架構之下，結合點對點傳輸網(wǎng)絡的共享傳輸，是本文實現(xiàn)的一個方向。在架構上，可以將多個獨立的CDN使用P2P技術互相連接起來[4]，也可以將中心化的P2P網(wǎng)絡與傳統(tǒng)CDN技術融合而成的HCDN模型，并將邊緣服務器作為中心化P2P中的索引服務器[5]，在此基礎上，文獻[6]沿用了模型，進行了一些仿真測試，但都沒有可行的實現(xiàn)。本文基于內容分發(fā)網(wǎng)絡的網(wǎng)絡拓撲結構，將點對點傳輸網(wǎng)絡融入其中，使用高級消息隊列AMQP進行控制信息的傳輸，連接整個網(wǎng)絡，并負責部分小規(guī)模數(shù)據(jù)的分發(fā)，使用P2P網(wǎng)絡進行大規(guī)模數(shù)據(jù)的分發(fā)，實現(xiàn)數(shù)據(jù)分發(fā)系統(tǒng)。

1 相關工作

1.1 AMQP技術

高級消息隊列協(xié)議(Advanced Message Queuing Protocol，AMQP)，是一個架設在計算機網(wǎng)絡應用層之上，提供統(tǒng)一消息服務的高級消息傳輸隊列協(xié)議[7]。該技術需要架設中轉服務器，系統(tǒng)運行時，發(fā)送端將消息投遞至中轉服務器，由于發(fā)送端投遞關鍵字的不同，中轉服務器根據(jù)這些不同的關鍵字將消息分發(fā)至不同的消息接收端，實現(xiàn)發(fā)送端與接收端的異步互聯(lián)。同時，中轉服務器端負責消息的維護和整體系統(tǒng)的負載均衡。該技術通過不同的編程語言編寫，可以在不同的編程語言中運行。RabbitMQ是基于AMQP標準實現(xiàn)的一個典型的開源消息中間件。

通俗來講，AMQP是架設在計算機網(wǎng)絡應用層之上，自恰的一套傳輸協(xié)議。而其典型設計當屬RabbitMQ服務器，是由Erlang語言編寫的，用于集群消息分發(fā)的開源程序。RabbitMQ擁有幾種不同的消息分發(fā)傳輸模式，分別是消息直傳模式、廣播/訂閱模式和接收關鍵字模式。其中，直傳模式生產(chǎn)者將生產(chǎn)的消息推送至消息隊列，所有關注該隊列的消費者都可以接收該消息，接收后該消息消失。廣播/訂閱模式中，生產(chǎn)者在產(chǎn)生消息之后，將該消息投遞至所有訂閱該消息的接收隊列之中，供消費者接收。在接收關鍵字模式中，生產(chǎn)者只將生產(chǎn)的消息投遞至監(jiān)聽關鍵字符合的隊列之中。

1.2 P2P網(wǎng)絡

P2P(peer-to-peer)網(wǎng)絡，又稱對等式網(wǎng)絡，是一種沒有中央服務器，依靠眾多的用戶節(jié)點組成的一個龐大的互聯(lián)網(wǎng)絡。該類網(wǎng)絡的設計作用在于，依托眾多的用戶節(jié)點，互聯(lián)互通傳輸資源，以減少局部網(wǎng)絡流量過大、負載過高為宗旨，同時還可降低單點故障帶來的問題。在P2P網(wǎng)絡中，每個節(jié)點既是用戶節(jié)點，又是服務節(jié)點，符合網(wǎng)絡共享的思維。具體來說，P2P網(wǎng)絡分為結構化的P2P網(wǎng)絡、非結構化的P2P網(wǎng)絡和松散結構的P2P網(wǎng)絡。相應地，結構化的P2P網(wǎng)絡在節(jié)點之間互相連接，構成有一定規(guī)則的拓撲結構以供資源搜索時使用，典型代表有Chord、Kademlia等。非結構化的P2P網(wǎng)絡節(jié)點之間相互連接，但沒有形成有結構的網(wǎng)絡拓撲，節(jié)點間通行依靠廣播形式來完成，典型代表有Gnutella。松散結構的P2P網(wǎng)絡介于有結構的P2P網(wǎng)絡與無結構的P2P網(wǎng)絡之間，通常會有中央服務器存在，典型代表有Freenet。

綜上探討后可知，結構化的P2P網(wǎng)絡效率最高，且以Kademlia網(wǎng)絡結構為代表。實現(xiàn)這種網(wǎng)絡結構的主要程序有BitTorrent和eMule。BitTorrent是一款由python語言編寫的開源程序，BitTorrent協(xié)議是架構在TCP/IP層上的一個傳輸通信協(xié)議，是一個應用層協(xié)議。在BitTorrent協(xié)議中，可以通過2種方式請求資源。一種是通過結構化的DHT(Distributed Hash Table)網(wǎng)絡，另外一種是通過種子文件來請求資源。本文中用到的是改進后的DHT網(wǎng)絡來分發(fā)資源。

2 框架設計及實驗分析

2.1 系統(tǒng)架構

從架構層面來說，系統(tǒng)由2個模塊組成，分別是：控制模塊與傳輸模塊。對于前者，在控制層面來講，控制信息是由AMQP來傳輸發(fā)送的，主要由RabbitMQ來實現(xiàn)。而傳輸模塊分為2部分，也就是：AMQP傳輸部分和P2P傳輸部分。

從網(wǎng)絡拓撲結構來說，系統(tǒng)可簡單地看作一個三層網(wǎng)絡拓撲結構，如圖1所示。在網(wǎng)絡結構中，多媒體數(shù)據(jù)是多媒體資源的生產(chǎn)者，負責生產(chǎn)多媒體資源，通常是各類多媒體平臺。網(wǎng)絡拓撲結構的第一層是中央服務器，監(jiān)控著整個系統(tǒng)的資源調取分發(fā)，存儲著所有的多媒體資源。網(wǎng)絡拓撲的第二層是中轉服務器，存儲有資源副本，架設在各個不同的地區(qū)，掌控著向本地區(qū)用戶的資源分發(fā)。網(wǎng)絡拓撲的第三層是終端用戶，是多媒體資源的請求者和使用者。

圖1 消息分發(fā)系統(tǒng)的網(wǎng)絡架構

2.2 系統(tǒng)任務調度

為了使整個系統(tǒng)獲得較好的分發(fā)速度，需要使每個服務器都能發(fā)揮優(yōu)質效能。本系統(tǒng)使用高級消息隊列RabbitMQ進行各個服務器與客戶端之間的調度命令傳輸。在系統(tǒng)運行過程中，維護一個控制信息的消息通道，主服務器與地區(qū)服務器之間通過此通道傳輸控制命令。

當系統(tǒng)運行初期，服務器通過控制信息隊列向客戶端廣播一條控制信息，確定當前在線的客戶端及其狀態(tài)。當服務器需要向客戶端分發(fā)消息時，服務器端通過隊列傳輸接下來所要發(fā)送的文件的信息，各個客戶端接收到服務器端發(fā)送的消息信息后，返回一個接收反饋信息，然后根據(jù)所傳輸?shù)南⒌男畔ⅲ南鬏旉犃小７掌鞫嗽谙l(fā)送前，會發(fā)送一個確認消息，確認當前消息隊列的建立情況，滿足需求后向該通道廣播對應的消息。當所需要發(fā)送的消息過大時，系統(tǒng)會使用P2P方式進行多媒體文件的分發(fā)，會先發(fā)送一個種子的長度信息給各個需要接收該消息的客戶端，此后客戶端反饋接收情況。接下來，服務器端向客戶端傳輸即將需要分發(fā)的消息文件的種子文件，客戶端收到完整的種子文件后，給客戶端發(fā)送一個反饋，基于此客戶端將開啟本地P2P下載進程，通過該種子文件中的信息下載該種子文件。其消息隊列任務調度如圖2所示。

研究可知，系統(tǒng)在運行時維護一個當前在線節(jié)點列表，當有分發(fā)文件到達時，系統(tǒng)讀取新來的文件，如果該文件之前已獲發(fā)送，則不作處理；否則，根據(jù)文件的大小，使用對應分發(fā)操作對文件進行分發(fā)。關于該算法的主要邏輯可表述如下。

While(True):

BoradcastToNode()

FlushNodeStatus()

nodeList=LoadOnlineNode()

mediaFiles=LoadMultiMediaData()

fornewFileinmediaFiles:

ifHasBeenDistribute(newFile) == True：

continue

ifGetFileSize(newFile)

fornodeinnodeList:

DistributeByAMQP(node,newFile)

else :

fornodeinnodeList:

DistributeByP2P(node,newFile)

UpdateFileStatus(newFile)

sleep(section)

圖2 消息請求隊列任務調度流程

2.3 AMQP傳輸模塊

在內容分發(fā)網(wǎng)絡中，對于小文件，使用P2P網(wǎng)絡進行分發(fā)往往會加大網(wǎng)絡中的資源消耗，且分發(fā)效率提升不明顯。因此，本系統(tǒng)擬采用RabbitMQ隊列對小文件進行分發(fā)。

在文件分發(fā)過程中，首先服務器讀取當前多媒體文件需要下發(fā)的節(jié)點，將需要下發(fā)文件的文件信息通過控制傳輸通道傳輸給當前在線的需要接收的節(jié)點。當客戶端接收到傳送而來的文件基本信息后，將自己的節(jié)點信息和接收到的文件配置信息驗證反饋給服務器，同時建立相應的文件接收隊列。而后服務器將通過控制通道，收集已經(jīng)建立了通道的用戶節(jié)點的信息，向建立完成接收通道的節(jié)點分發(fā)文件內容。在客戶端，異步接收該文件，并在接收結束后返回一個正確接收反饋。研究設計流程如圖3所示。

圖3 隊列文件分發(fā)流程

在使用RabbitMQ對小文件進行分發(fā)時，可以選擇2種分發(fā)方式，分別是直接分發(fā)模式和訂閱/廣播分發(fā)模式。如果只需要向部分節(jié)點傳輸文件，優(yōu)先使用直接分發(fā)模式，逐一向這些節(jié)點分發(fā)文件，這樣可以減少廣播控制信息帶來的流量，但是在投遞分發(fā)的過程中會增加一定的傳輸工作量。如果需要向全部節(jié)點分發(fā)文件，可優(yōu)先使用訂閱/廣播模式，這種情況下，廣播控制信息對整個網(wǎng)絡的影響被縮小，同時訂閱/廣播模式使用較少的文件副本，減少了文件磁盤操作的工作量。

2.4 P2P傳輸模塊

在內容分發(fā)網(wǎng)絡中，對于較大的文件，如果利用一對多的傳輸方式，使得單一節(jié)點的網(wǎng)絡帶寬成為整個系統(tǒng)的性能瓶頸，且一對多的傳輸方式，就會出現(xiàn)發(fā)送節(jié)點的網(wǎng)絡擁塞，導致分發(fā)效率降低。而P2P傳輸網(wǎng)絡則完美解決了這一研究課題。結構化的P2P網(wǎng)絡BitTorrent，使用的是多對多的傳輸方式，每個節(jié)點在請求未接收到的文件分片的同時，也在分發(fā)已經(jīng)接收到的文件分片[8-9]。這樣雖然某個單一節(jié)點的接收速率有走低跡象，但卻降低了整個系統(tǒng)的接收時間。因此，使用P2P網(wǎng)絡進行分發(fā)可以加快分發(fā)效率，并明顯減少全局分發(fā)時間。因此，本系統(tǒng)將采用修改后的BitTorrent網(wǎng)絡對大文件進行分發(fā)。在文件分發(fā)過程中，采用如下邏輯：

Step1中央服務器讀取目錄，掃描需要分發(fā)的文件，并生成文件的種子文件。

Step2中央服務器將文件的種子文件信息下發(fā)至需要接收該文件的節(jié)點。中央服務器接收到接收節(jié)點接收通道建立完成的反饋后，使用該通道傳輸種子文件。

Step3中央服務器將文件信息通過通道下發(fā)至二級服務器。待二級服務器建立接收通道后，中央服務器向二級服務器下發(fā)文件。

Step4中央服務器接收到二級服務器接收完成的反饋，向所有終端用戶分發(fā)接收文件的文件信息，節(jié)點在接收到文件信息后，開啟BitTorrent下載，解析文件的種子信息，向二級服務器請求下載。

Step5終端節(jié)點在文件接收完成后，向服務器端發(fā)送接收完成反饋。

Step6如果大部分節(jié)點接收完成配置，則返回Step1；否則等待終端節(jié)點接收。

在BitTorrent網(wǎng)絡中，能夠做到以較高的傳輸速度共享文件，究其原因即在于其結構化的網(wǎng)絡拓撲和文件分片共享機制。當請求產(chǎn)生時，客戶端通過迭代的方式向整個DHT(Distribute Hash Table)網(wǎng)絡查詢該內容文件的所有者，并向部分所有者請求該文件。其中，不同于原來的BitTorrent網(wǎng)絡，查詢到的資源擁有者是隨機獲取的，不同的請求者查詢到的資源擁有者也是不同的。在文件的傳輸過程中，BitTorrent網(wǎng)絡的傳輸策略是優(yōu)先向不同的請求者傳輸不同的文件分片，即優(yōu)先分發(fā)稀有分片。這樣，可以更早地開啟請求者之間的互傳，使整個系統(tǒng)的內容文件整體分發(fā)效率盡快達到最優(yōu)。在研究過程中的消息請求分片傳輸則如圖4所示。

圖4 消息請求分片傳輸

2.5 實驗分析

實驗主要選擇了平均下載速度作為測試結果的主要衡量標準，這一參數(shù)能夠體現(xiàn)系統(tǒng)整體的分發(fā)性能，受到波動的影響較小。測試數(shù)據(jù)的平均速率為文件大小與文件從分發(fā)開始到所有節(jié)點均接收到的時間的比值，而非單一節(jié)點接收到文件。所有實驗都在數(shù)臺服務器之間設計實現(xiàn)，實驗過程中使用的平臺配置信息見表1。

表1 實驗平臺配置信息

文中，針對使用RabbitMQ或使用BitTorrent網(wǎng)絡在不同節(jié)點數(shù)量下的分發(fā)傳輸速率，可得到的研究運行后的實驗結果如圖5所示。由圖5可以看出，在分發(fā)較小規(guī)模的文件(100 MB)時，當節(jié)點數(shù)目較小時，RabbitMQ傳輸占有絕對的優(yōu)勢，而當請求節(jié)點數(shù)目增加時，RabbitMQ傳輸也仍是優(yōu)于BitTorrent傳輸?shù)模皇莾?yōu)勢差距在逐漸縮小。在節(jié)點數(shù)量不斷增加的情況下，由于機器性能與網(wǎng)絡的原因，傳輸速率有所下降。由此說明RabbitMQ適合一定規(guī)模下的小文件傳輸，具有較高的傳輸效率。

圖5 不同數(shù)量節(jié)點下的100 MB資源分發(fā)速率圖

Fig. 5 100 MB resource distribution rate diagram under different number of nodes

在此基礎上，研究進一步得到了不同數(shù)量節(jié)點下的1 000 MB資源分發(fā)速率如圖6所示。由圖6可以看出，當傳輸文件的大小由100 MB提升到1000 MB時，在節(jié)點數(shù)目為10時，由于系統(tǒng)資源利用率并未達到最大，RabbitMQ傳輸速率依然高于BitTorrent傳輸；但當節(jié)點數(shù)目不斷增加時，系統(tǒng)資源負載均衡的情況下，BitTorrent網(wǎng)絡的分片互傳機制已逐漸顯現(xiàn)出優(yōu)勢，BitTorrent網(wǎng)絡的傳輸已高于RabbitMQ網(wǎng)絡。由此說明BitTorrent更適合大文件的傳輸，在節(jié)點眾多的情況下傳輸效率頗高。

最后，針對RabbitMQ傳輸、BitTorrent傳輸與本系統(tǒng)傳輸不同大小文件的速率則如圖7所示。測試數(shù)據(jù)的計算的時間為從文件分發(fā)開始到結束。由圖7可以看出，整個文件分發(fā)的過程中，由于本系統(tǒng)對RabbitMQ傳輸和BitTorrent傳輸進行了部分簡化與修改，并在此基礎上增加了一些傳輸控制，故而對全規(guī)模段文件均可獲得較好的傳輸速率。在傳輸小文件時，初始的控制信息傳輸在整體傳輸過程中占了較高的比例，所以在文件只有1MB大小時，傳輸速率偏低。在傳輸大文件時，控制消息所占的比例降低，傳輸速度波動趨于平穩(wěn)。本次研發(fā)設計充分發(fā)揮了節(jié)點性能，一定程度上降低了服務器的負載，提升了整個傳輸過程的效率。

圖6 不同數(shù)量節(jié)點下的1 000 MB資源分發(fā)速率圖

Fig. 6 1 000 MB resource distribution rate graph under different number of nodes

圖7 單機模擬60節(jié)點分發(fā)不同規(guī)模資源速率圖

Fig. 7 The speed of a single machine simulating 60 nodes to distribute different scale resources

3 結束語

本文從計算機網(wǎng)絡入手，圍繞著大規(guī)模網(wǎng)絡下的可靠的數(shù)據(jù)請求分發(fā)問題，首先針對當前流行的AMQP和P2P網(wǎng)絡，闡述了這2種網(wǎng)絡的特性，并展開了優(yōu)劣勢分析；其次，根據(jù)這些網(wǎng)絡的特點，提出了將這兩者進行結合的研究設想，進而探討給出了對應的系統(tǒng)設計與架構；最后，基于設計的系統(tǒng)框架，實現(xiàn)了結合RabbitMQ與BitTorrent的消息分發(fā)系統(tǒng)，而且通過實驗分析了新系統(tǒng)的性能，并與原有的2種單獨RabbitMQ網(wǎng)絡或者BitTorrent網(wǎng)絡進行了分發(fā)對比，實驗結果顯示了新架構的優(yōu)越性。