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

劉飛揚(yáng)， 葉 麟， 余翔湛， 趙俊達(dá)

(哈爾濱工業(yè)大學(xué) 計(jì)算機(jī)科學(xué)與技術(shù)學(xué)院， 哈爾濱 150001)

0 引 言

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

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

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

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

1 相關(guān)工作

1.1 AMQP技術(shù)

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

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

1.2 P2P網(wǎng)絡(luò)

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

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

2 框架設(shè)計(jì)及實(shí)驗(yàn)分析

2.1 系統(tǒng)架構(gòu)

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

從網(wǎng)絡(luò)拓?fù)浣Y(jié)構(gòu)來說，系統(tǒng)可簡(jiǎn)單地看作一個(gè)三層網(wǎng)絡(luò)拓?fù)浣Y(jié)構(gòu)，如圖1所示。在網(wǎng)絡(luò)結(jié)構(gòu)中，多媒體數(shù)據(jù)是多媒體資源的生產(chǎn)者，負(fù)責(zé)生產(chǎn)多媒體資源，通常是各類多媒體平臺(tái)。網(wǎng)絡(luò)拓?fù)浣Y(jié)構(gòu)的第一層是中央服務(wù)器，監(jiān)控著整個(gè)系統(tǒng)的資源調(diào)取分發(fā)，存儲(chǔ)著所有的多媒體資源。網(wǎng)絡(luò)拓?fù)涞牡诙邮侵修D(zhuǎn)服務(wù)器，存儲(chǔ)有資源副本，架設(shè)在各個(gè)不同的地區(qū)，掌控著向本地區(qū)用戶的資源分發(fā)。網(wǎng)絡(luò)拓?fù)涞牡谌龑邮墙K端用戶，是多媒體資源的請(qǐng)求者和使用者。

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

2.2 系統(tǒng)任務(wù)調(diào)度

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

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

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

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 消息請(qǐng)求隊(duì)列任務(wù)調(diào)度流程

2.3 AMQP傳輸模塊

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

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

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

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

2.4 P2P傳輸模塊

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

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

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

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

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

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

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

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

圖4 消息請(qǐng)求分片傳輸

2.5 實(shí)驗(yàn)分析

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

表1 實(shí)驗(yàn)平臺(tái)配置信息

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

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

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

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

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

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

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

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

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

3 結(jié)束語

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