基于P2P的分布式遙感影像分發(fā)系統(tǒng)設計

杜佳恒 王棟 趙亞萌 臧文乾 宋奇

摘要：隨著遙感行業(yè)的發(fā)展，單一遙感數(shù)據(jù)越來越多，數(shù)據(jù)需求量也日益增大。遙感數(shù)據(jù)分發(fā)中心需要提高對外分發(fā)能力才能應對日益增長的數(shù)據(jù)分發(fā)請求。鑒于遙感數(shù)據(jù)分發(fā)中心的網(wǎng)絡帶寬有限，設計了一種基于P2P的分布式遙感影像分發(fā)方案。構(gòu)建資源鏡像節(jié)點，每個節(jié)點在分發(fā)過程中同時從多個資源鏡像獲取數(shù)據(jù)，并且分發(fā)節(jié)點也作為資源鏡像為其它節(jié)點提供數(shù)據(jù)，有效緩解了中心的分發(fā)壓力。同時，實現(xiàn)了一種監(jiān)測端到端網(wǎng)絡傳輸速率的分發(fā)機制，加快了當前節(jié)點的任務處理速率。

關(guān)鍵詞關(guān)鍵詞：遙感數(shù)據(jù)；P2P；資源鏡像；傳輸速率

DOIDOI：10.11907/rjdk.161448

中圖分類號：TP319文獻標識碼：A文章編號文章編號：16727800（2016）007007403

0引言

遙感數(shù)據(jù)作為重要的信息資源，不僅需要妥善地加以保存，更需要盡可能多地向各類用戶進行分發(fā)和共享，使數(shù)據(jù)活用起來，實現(xiàn)其更大價值。隨著遙感技術(shù)的發(fā)展，遙感圖像文件越來越大，各行業(yè)對遙感數(shù)據(jù)的需求量也越來越多，使得遙感數(shù)據(jù)中心對外分發(fā)數(shù)據(jù)量大增。面對大量的分發(fā)需求和中心有限的網(wǎng)絡帶寬，研究如何快速高效地對外分發(fā)數(shù)據(jù)變得越來越迫切。

鑒于遙感單一影像文件大、總體數(shù)據(jù)海量的特點，針對如何保證遙感數(shù)據(jù)分發(fā)系統(tǒng)能有序、規(guī)范、高效地為各行業(yè)用戶提供共享數(shù)據(jù)問題，沈夏炯、張振鵬實現(xiàn)了一種基于單隊列控制模式的分發(fā)方式。遙感數(shù)據(jù)集中存儲在數(shù)據(jù)分發(fā)中心，由數(shù)據(jù)分發(fā)中心的數(shù)據(jù)庫管理系統(tǒng)負責對其進行統(tǒng)一整理、存儲和統(tǒng)計，所有的分發(fā)請求按先后次序排隊處理。此時，網(wǎng)絡帶寬壓力主要集中在數(shù)據(jù)分發(fā)中心，在老分發(fā)請求未處理完的情況下新請求將會處于掛起狀態(tài)，隨著分發(fā)請求的增多，積壓的分發(fā)量也越來越大。

針對數(shù)據(jù)分發(fā)量越來越大而分發(fā)效率逐漸降低的弊端，結(jié)合現(xiàn)有系統(tǒng)架構(gòu)，本文基于P2P技術(shù)構(gòu)建資源鏡像節(jié)點，實現(xiàn)了一種基于P2P的分布式遙感影像分發(fā)方案，提出并實現(xiàn)了一種監(jiān)測端到端網(wǎng)絡傳輸速率的分發(fā)機制。

1分布式遙感影像分發(fā)方案

1.1分發(fā)結(jié)構(gòu)改進

遙感影像數(shù)據(jù)與諸如視頻、音頻、安裝包等常用且重復率高的數(shù)據(jù)不同，如果構(gòu)建P2P共享網(wǎng)絡，則使用頻率高的資源會在共享網(wǎng)絡中大面積覆蓋。由于需要遙感數(shù)據(jù)的用戶存在行業(yè)、地區(qū)差異，因而同一個遙感數(shù)據(jù)一般只被一個終端下載。如果采用多個終端（BT客戶端）之間共享策略，數(shù)據(jù)的實際共享率實際上并不高，最后數(shù)據(jù)仍需從分發(fā)中心獲取。

鑒于上述原因，本文采用混合式對等網(wǎng)絡＼[23＼]的思想設計由中心管控節(jié)點管理和記錄索引信息，各分發(fā)節(jié)點存儲資源數(shù)據(jù)的分布式遙感影像分發(fā)架構(gòu)。預先將已有的一部分遙感數(shù)據(jù)分散地存儲到各分發(fā)節(jié)點，分發(fā)節(jié)點也作為資源節(jié)點，同時也為其它分發(fā)節(jié)點提供資源，形成一個大的資源共享網(wǎng)絡，如圖1所示。

改進后，每個資源節(jié)點都是中心節(jié)點的鏡像或是部分鏡像，新的分發(fā)請求可以將壓力分散到不同的分發(fā)節(jié)點上，以緩解中心節(jié)點的一部分壓力。當中心節(jié)點生產(chǎn)出新數(shù)據(jù)時，在任務空閑時選擇當前網(wǎng)絡狀況最好的分發(fā)子節(jié)點傳輸新數(shù)據(jù)，逐步將新數(shù)據(jù)分散出去。這樣新數(shù)據(jù)請求在各分散節(jié)點的命中率會更高，總體分發(fā)效率也會更好。

1.2中心節(jié)點數(shù)據(jù)索引

中心管控節(jié)點負責存儲各子節(jié)點資源索引，當沒有子節(jié)點存有所需數(shù)據(jù)時，則中心節(jié)點還需要作為唯一的分發(fā)節(jié)點將數(shù)據(jù)分發(fā)到其它節(jié)點。分發(fā)中心存有數(shù)據(jù)的元數(shù)據(jù)信息即索引信息，包括數(shù)據(jù)名、數(shù)據(jù)所在節(jié)點服務器地址、數(shù)據(jù)大小等元數(shù)據(jù)信息。

1.3數(shù)據(jù)分塊及傳輸機制

為了從不同節(jié)點上獲取同一數(shù)據(jù)資源，需要將整個資源文件進行分片，下載節(jié)點從不同的資源節(jié)點獲取不同位置的數(shù)據(jù)片，最后合并成完整的文件。每個分發(fā)節(jié)點設計數(shù)據(jù)獲取網(wǎng)絡接口：

輸入：給定文件名和起始字節(jié)數(shù)以及需要字節(jié)數(shù)。

輸出：資源的相應部分加密后的字節(jié)流。

下載方通過調(diào)用WebService網(wǎng)絡接口的方式從數(shù)據(jù)提供方獲取所需要的數(shù)據(jù)片段。下載節(jié)點先根據(jù)資源碎片號和分片大小確定需要獲取文件的起始文件位置和終止文件位置，從數(shù)據(jù)資源節(jié)點獲取加密過的文件碎片信息，接收成功后解密寫入碎片文件。全部接收完成后將所有碎片文件合并為原始的資源文件。傳輸過程如圖2所示。

2.1網(wǎng)絡傳輸速率檢測

由于不同分發(fā)節(jié)點部署的地理位置以及接入的ISP（網(wǎng)絡提供商）不同，因而網(wǎng)絡帶寬一般有所差異，它們的分發(fā)能力也不一樣。還有一些節(jié)點ISP分配的帶寬很高，但其所處的網(wǎng)絡環(huán)境導致實際可用帶寬并沒有那么穩(wěn)定。因此，在分配分發(fā)任務時檢測當前節(jié)點和配對節(jié)點當前端到端的可用帶寬很有必要。為了保證總體分發(fā)效率最高，系統(tǒng)根據(jù)分發(fā)任務處理過程中檢測端到端可用帶寬并根據(jù)當前傳輸速率動態(tài)調(diào)整分發(fā)任務，讓系統(tǒng)整體網(wǎng)絡利用率更高。

2.2中心調(diào)度

中心節(jié)點在單隊列控制模式的分發(fā)調(diào)度基礎上，在其分發(fā)任務處于空閑的情況下，執(zhí)行新數(shù)據(jù)推送任務。推送任務選擇傳輸速率最高而又需要存儲新鏡像的節(jié)點，對其推送最新數(shù)據(jù)。

具體調(diào)度流程如下：①檢測中心節(jié)點控制隊列是否有分發(fā)任務，如有則等待，沒有則轉(zhuǎn)②；②中心節(jié)點各分發(fā)節(jié)點發(fā)送數(shù)據(jù)包，根據(jù)響應時間確定網(wǎng)絡傳輸速率，選擇速率最優(yōu)的節(jié)點；③查詢所選擇的節(jié)點，看中心索引是否將近一個月的數(shù)據(jù)全部存儲完畢，有則選取速率次之的節(jié)點繼續(xù)③；④選擇最新的一景數(shù)據(jù)推送到所選擇的節(jié)點，推送完畢后繼續(xù)①。

分發(fā)節(jié)點接到用戶下載請求后，如果自身節(jié)點沒有所需要的資源，則查詢中心索引得到存有該資源的其它節(jié)點信息，然后開啟多個線程從不同節(jié)點主動拉取，并根據(jù)耗時動態(tài)調(diào)整線程數(shù)，讓更多線程從速率快的節(jié)點下載。

步驟1：資源獲取節(jié)點查詢中心索引信息，確定資源基本信息和資源分布情況。假設資源大小為S，每塊大小為s，可提供資源節(jié)點數(shù)為n，可以提供資源的節(jié)點為N1、N2……Nn。

步驟2：資源信息初始化。計算出分塊數(shù)b。定義節(jié)點已經(jīng)獲取的片段數(shù)Ns1、Ns2…Nsn為0，以及片段從該節(jié)點傳輸平均耗時t1、t2……t3為-1，最大線程數(shù)為m。

步驟3：同時開啟thread1、thread2…threadn（n為可提供資源節(jié)點數(shù)）線程不斷獲取下一個片段。任何一個線程只要片段獲取任務完成，便可統(tǒng)計出其耗時為T。重新計算該節(jié)點片段獲取平均耗時并將已經(jīng)獲取片段數(shù)加1。ti=Nsiti+TNsi+1步驟4：當線程中一次片段獲取任務完成時，比較t1，t2……tn找出最少時間對應的Ni，再開啟一個線程從Ni節(jié)點獲取一個新片段直到Ni節(jié)點占用的線程數(shù)到最大指定數(shù)m。如果片段獲取失敗，則將該片段號寫入錯誤棧并對該片段資源提供節(jié)點的平均耗時進行處理修改。該節(jié)點的平均耗時為最大平均耗時ti=max{∪nj=1tj}。

步驟5：當b數(shù)量的片段都進行過一次任務調(diào)用，檢查錯誤棧，如果存在沒有成功獲取的片段，則對于錯誤棧中的片段從步驟3開始重新獲取。

步驟6：所有片段都成功獲取完成后，對b個片段文件進行合并操作。新建一個以資源名為文件名的文件，使用隨機讀寫的方式將每一個片段寫進文件對應的位置。

3實驗測試

3.1實驗環(huán)境

為了驗證本文提出的數(shù)據(jù)分發(fā)方式的實用性，選擇以下測試環(huán)境和系統(tǒng)初始環(huán)境進行模擬實驗：

測試環(huán)境：千兆局域網(wǎng)內(nèi)4個分發(fā)節(jié)點，中心節(jié)點Nc，限制其上傳、下載速率Vc為1m/s；分發(fā)節(jié)點N1，限制其上傳、下載速率V1為512k/s；分發(fā)節(jié)點N2，限制其上傳、下載速率V2為1m/s；分發(fā)節(jié)點N3，限制其上傳、下載速率V3為2m/s。

初始條件：中心節(jié)點錄入5，景數(shù)據(jù)大小S約為2 122M，3個用戶分別從N1、N2、N3這3個節(jié)點依次提交下載請求。統(tǒng)計數(shù)據(jù)從中心節(jié)點分發(fā)到所在節(jié)點的等待時間。

3.2單隊列控制模式

該模式理論上是用戶從所在節(jié)點將請求提交到中心節(jié)點，然后中心節(jié)點按先后次序依次推送到其所在節(jié)點，最后用戶將其下載到本地。其理論等待時間Ti為：Ti=∑i-1j=1Tj+Smin{Vc，Vi}（Tj為隊列中第j個任務處理時間）其理論等待時間和實際等待時間如表1所示。

本文實現(xiàn)中心節(jié)點主動監(jiān)測，其在上行帶寬不滿的情況下向資源占有率不滿的節(jié)點推送新數(shù)據(jù)。分發(fā)節(jié)點根據(jù)資源在系統(tǒng)中的分布位置從不同節(jié)點獲取數(shù)據(jù)，最后合并資源供用戶下載。因為數(shù)據(jù)是動態(tài)傳輸方式，所以其理論等待時間Ti存在最壞情況和最好情況，實際等待時間大致處于二者之間。

最壞情況下，資源只存在于中心節(jié)點Ti=∑i-1j=1Tj+Smin{Vc，Vi}；最好情況下，資源平均分布在其它節(jié)點Ti=Smin{Vi，∑mj=1Vj}（m為有該資源的節(jié)點數(shù)）。

如果添加多個節(jié)點作為鏡像站，∑mj=1Vj理論值可以是無限大，則單一節(jié)點獲取數(shù)據(jù)的速率只取決于其自身網(wǎng)絡傳輸速率Vi。實際等待時間如表2所示。

表2實際等待時間用戶所在

節(jié)點節(jié)點最大上傳速率（k/s）節(jié)點最大下載速率（k/s）數(shù)據(jù)總大?。∕）等待時間（傳輸時間）（s）User1N15125122 1224 763User2N21 024 1 0242 1226 374User3N32 0482 0482 1225 5764結(jié)語

經(jīng)過理論分析和實驗驗證，構(gòu)建資源鏡像節(jié)點，讓分發(fā)任務從多個節(jié)點獲取數(shù)據(jù)，并且選擇網(wǎng)絡傳輸速率最好的節(jié)點盡可能多地獲取數(shù)據(jù)能使得分發(fā)任務平均等待時間縮短。在實際環(huán)境中，只要在廣域網(wǎng)大量部署分發(fā)節(jié)點并存儲一部分中心節(jié)點資源鏡像，需要數(shù)據(jù)的行業(yè)和機構(gòu)作為分發(fā)節(jié)點只需提高自身網(wǎng)絡帶寬就可以擁有相應的數(shù)據(jù)獲取能力。

參考文獻：

高斌.高分辨率遙感影像共享關(guān)鍵技術(shù)研究與實現(xiàn).成都：電子科技大學，2014.

王學龍，張璟.P2P關(guān)鍵技術(shù)研究綜述[J].計算機應用研究，2010（3）：801805.

何帥.P2P文件共享系統(tǒng)的設計與實現(xiàn).武漢：華中科技大學，2012.