遙感數(shù)據(jù)分發(fā)系統(tǒng)單隊列控制模式的設計與實現(xiàn)

沈夏炯　張振鵬　段勝強

摘 要： 鑒于遙感單一影像文件大、總體數(shù)據(jù)海量的特點，針對如何保證遙感數(shù)據(jù)分發(fā)系統(tǒng)能有序、規(guī)范、高效地為各行業(yè)用戶提供共享數(shù)據(jù)問題，對遙感數(shù)據(jù)分

發(fā)系統(tǒng)的硬件部署框架結構進行分析，提出一種基于固定容量的單隊列控制模式解決方案，并對其進行實現(xiàn)。通過單隊列控制模式的控制流程及策略，系統(tǒng)穩(wěn)定并可靠地完成了數(shù)據(jù)分發(fā)任務，最終保證了系統(tǒng)的運行性能和數(shù)據(jù)的傳輸質量，滿足了用戶對遙感影像的獲取需求。

關鍵詞： 遙感數(shù)據(jù)； 分發(fā)； 隊列； 控制

中圖分類號：TP399 文獻標志碼：A 文章編號：1006-8228（2015）05-07-03

Abstract： In consideration of the characteristics of remote sensing image data that the single file is large and the total data is massive， aiming at how to ensure the remote sensing data distribution system orderly， standardized and efficiently provides the users in various industries with shared data， a hardware deployment framework of remote sensing data distribution system is analyzed， and a single queue control mode with fixed capacity is proposed and realized. By controlling the processes and strategies of single queue control mode， the system is stable and reliable to complete the data distribution task， ensures the performance and the transmission quality of data， meets the needs of users to access remote sensing images.

Key words： remote sensing data； distribution； queue； control

0 引言

隨著高分辨率系列遙感衛(wèi)星的不斷升空及獲取遙感影像技術的不斷成熟，每天獲取的遙感影像數(shù)據(jù)量也在急劇增長。面對海量的遙感數(shù)據(jù)，建立一套遙感影像數(shù)據(jù)分發(fā)系統(tǒng)，實現(xiàn)遙感數(shù)據(jù)資源的有序、規(guī)范、高效共享，為各行業(yè)用戶提供遙感影像的查詢與獲取很有必要。由于遙感數(shù)據(jù)的特殊性與信息安全的需要，遙感數(shù)據(jù)集中存儲在數(shù)據(jù)分發(fā)中心，由數(shù)據(jù)分發(fā)中心的數(shù)據(jù)庫管理系統(tǒng)負責對其進行統(tǒng)一整理、存儲和統(tǒng)計。單個遙感影像文件的大小通常在數(shù)百兆甚至更大，在數(shù)據(jù)分發(fā)過程中，占用網(wǎng)絡資源較多，傳輸壓力主要集中在數(shù)據(jù)分發(fā)中心。如何在網(wǎng)絡資源有限的環(huán)境下對到達數(shù)據(jù)分發(fā)中心的大批量數(shù)據(jù)分發(fā)請求進行處理，同時保證用戶的體驗與服務性能，是遙感影像數(shù)據(jù)分發(fā)系統(tǒng)中必須解決的問題。

如果采用傳統(tǒng)的方法，可以使用多線程技術對每一條到達的分發(fā)請求建立單獨線程處理，即立即響應請求的控制策略[3]，但這樣在大批量分發(fā)請求的環(huán)境下，會出現(xiàn)兩個問題：第一，數(shù)據(jù)分發(fā)中心將在服務器上不斷的創(chuàng)建銷毀線程，這是對系統(tǒng)性能和計算資源的浪費；第二，數(shù)據(jù)中心的網(wǎng)絡帶寬有限，在大量請求環(huán)境下，不僅降低系統(tǒng)的整體分發(fā)效率，同時還會增加數(shù)據(jù)傳輸出錯的概率。

針對遙感數(shù)據(jù)的特點及傳統(tǒng)分發(fā)控制方法的不足，本文實現(xiàn)基于固定容量大小的單隊列控制模式，通過控制數(shù)據(jù)分發(fā)中心處理分發(fā)請求的順序及數(shù)量，保證系統(tǒng)的運行性能和數(shù)據(jù)的傳輸質量，滿足多用戶多行業(yè)對遙感影像的獲取請求。

1 系統(tǒng)總體框架結構

遙感數(shù)據(jù)分發(fā)系統(tǒng)采用SOA架構設計，各子系統(tǒng)之間通過WebService進行消息通信，其部署架構圖如圖1所示。

遙感數(shù)據(jù)分發(fā)系統(tǒng)總體由1個數(shù)據(jù)分發(fā)中心和k個板塊中心構成。通過在數(shù)據(jù)分發(fā)中心和用戶中間添加板塊中心層，將用戶登錄、訂單管理和數(shù)據(jù)檢索等系統(tǒng)壓力轉移至板塊中心，隔離數(shù)據(jù)分發(fā)中心與用戶的操作，使得數(shù)據(jù)分發(fā)中心保持數(shù)據(jù)存儲及分發(fā)功能惟一性。板塊中心擁有用戶并負責管理自己的用戶，與數(shù)據(jù)分發(fā)中心始終保持系統(tǒng)已有遙感影像衛(wèi)星、傳感器類型、分辨率、經(jīng)緯度等元數(shù)據(jù)信息的同步。用戶從自己所注冊的板塊中心檢索符合要求的數(shù)據(jù)，通過板塊中心向數(shù)據(jù)分發(fā)中心提交數(shù)據(jù)獲取請求，數(shù)據(jù)分發(fā)中心將數(shù)據(jù)安全可靠的推送至對應的板塊中心。

數(shù)據(jù)分發(fā)中心由m個磁盤陣列、n個推送數(shù)據(jù)的服務站點和協(xié)同子系統(tǒng)組成。磁盤陣列即數(shù)據(jù)分發(fā)中心的數(shù)據(jù)庫管理系統(tǒng)，主要負責組織、存儲和管理系統(tǒng)的數(shù)據(jù)，部署在內網(wǎng)環(huán)境中，以保證數(shù)據(jù)的安全；推送站點主要功能是將用戶需要的數(shù)據(jù)安全、可靠的從磁盤陣列推送至板塊中心。

協(xié)同子系統(tǒng)負責與各個板塊中心、磁盤陣列和推送站點之間的消息通信，控制數(shù)據(jù)傳輸?shù)牧鞒蹋ＷC系統(tǒng)在網(wǎng)絡與系統(tǒng)資源有限的情況下高質量的數(shù)據(jù)分發(fā)，是整個系統(tǒng)的不可或缺的服務組件。協(xié)同子系統(tǒng)中的任務庫用來保存板塊中心信息、系統(tǒng)配置及數(shù)據(jù)分發(fā)過程產(chǎn)生的狀態(tài)信息等少量控制信息，任務控制隊列負責統(tǒng)一調度控制數(shù)據(jù)的分發(fā)，是整個系統(tǒng)的核心，也是本文討論的重點。

2 單隊列控制模式的設計

2.1 數(shù)據(jù)分發(fā)流程

從系統(tǒng)部署架構圖（圖1）中的數(shù)據(jù)流向可以得知，為保證數(shù)據(jù)的安全，系統(tǒng)分發(fā)過程中遙感數(shù)據(jù)首先在數(shù)據(jù)分發(fā)中心內部從磁盤陣列轉移至推送站點，再由推送站點負責將數(shù)據(jù)推送至板塊中心，最終到達用戶手中。具體的分發(fā)流程如下。

⑴ 用戶從板塊中心登錄系統(tǒng)，在檢索界面設置衛(wèi)星、傳感器、經(jīng)緯度和拍攝時間等條件，檢索滿足條件的遙感數(shù)據(jù)，可以通過查看數(shù)據(jù)的詳細元數(shù)據(jù)信息或縮略圖等方式確認自己需要的影像。

⑵ 將需要得到的數(shù)據(jù)作為訂單提交至板塊中心，板塊中心調用數(shù)據(jù)分發(fā)中心協(xié)同子系統(tǒng)提供的提交訂單WebService服務，提交數(shù)據(jù)分發(fā)任務。

⑶ 協(xié)同子系統(tǒng)將收到的分發(fā)任務存放在任務庫中，等待控制隊列的調度執(zhí)行，同時告知板塊中心任務提交成功處于等待處理狀態(tài)。

⑷ 執(zhí)行分發(fā)任務時，協(xié)同子系統(tǒng)選擇推送站點將用戶請求的數(shù)據(jù)推送到用戶所屬的板塊中心。

⑸ 推送成功后，由協(xié)同子系統(tǒng)通知相應的板塊中心用戶可以取走數(shù)據(jù)。

⑹ 數(shù)據(jù)在分發(fā)過程中如果出錯即任務失敗，則由協(xié)同子系統(tǒng)告知板塊中心，允許用戶再次提交對該數(shù)據(jù)的獲取請求。

2.2 隊列控制流程設計

從系統(tǒng)整體部署框架結構可以看出，系統(tǒng)實際運行時，每時每刻都可能有大量的下載請求到達數(shù)據(jù)分發(fā)中心，為保證各個板塊中心的數(shù)據(jù)需求，在傳輸數(shù)據(jù)上實現(xiàn)資源的公平分配，同時結合遙感數(shù)據(jù)大、傳輸時間不確定的特點，數(shù)據(jù)分發(fā)中心采用主動的、有固定容量的任務控制隊列針對板塊中心提交的數(shù)據(jù)分發(fā)任務進行統(tǒng)一調度控制。主動性是指隊列主動去任務庫中獲取等待處理的分發(fā)任務；固定容量指控制隊列的處理資源有限，系統(tǒng)同時運行的任務最多不會超過某個閾值，控制系統(tǒng)并行傳輸數(shù)據(jù)量，減小使用網(wǎng)絡資源，保證傳輸速度與質量。

在此模式下，用戶從板塊中心提交的數(shù)據(jù)分發(fā)請求不會立即得到響應，而是將請求的數(shù)據(jù)ID、數(shù)據(jù)名稱、數(shù)據(jù)類型等信息存儲在協(xié)同子系統(tǒng)的任務庫中，任務控制隊列主動從任務庫中獲取等待分發(fā)的任務進行處理，具體控制流程如圖2所示。

2.3 隊列控制流程描述

第一步：協(xié)同子系統(tǒng)將用戶從板塊中心提交的分發(fā)任務解析加入任務庫，同時發(fā)送消息通知控制隊列有新的分發(fā)任務到達，控制隊列如果處于正在“取出wait”狀態(tài)，則取消該狀態(tài)立即響應新到達的任務，開始分發(fā)流程，否則控制隊列忽略該消息，繼續(xù)執(zhí)行自己的控制流程。

第二步：控制隊列主動從任務庫中獲取等待分發(fā)的任務，如果任務庫中不存在等待分發(fā)的任務，控制隊列進入“取出wait”狀態(tài)，等待取消該狀態(tài)的消息到來。

第三步：成功獲取到下一條待處理的分發(fā)任務，如果控制隊列沒有空閑資源，即系統(tǒng)正在執(zhí)行的分發(fā)任務占滿了隊列容量，控制隊列進入“加入wait”狀態(tài)，等待取消該狀態(tài)的消息到來。

第四步：隊列有空閑資源時，則將分發(fā)任務加入隊列，同時減少隊列的空閑資源數(shù)量，該任務進入數(shù)據(jù)分發(fā)子流程，同時隊列繼續(xù)獲取下一條待處理的分發(fā)任務。

第五步：數(shù)據(jù)分發(fā)子流程中隊列解析任務相關信息并選擇推送站點將數(shù)據(jù)安全可靠地推送至指定位置（板塊中心的惟一FTP地址）。

第六步：推送站點將隊列分配的任務完成后，發(fā)送消息通知控制隊列一條分發(fā)任務處理完成，如果隊列處于“加入wait”狀態(tài)，則取消該狀態(tài)，將待處理的任務加入隊列，否則控制隊列忽略該消息，繼續(xù)執(zhí)行自己的控制流程。

2.4 隊列控制策略設計

對用戶不同需求提供對應的不同服務是保證網(wǎng)絡服務質量的一個重要原則[4]，數(shù)據(jù)分發(fā)中心為了保證對板塊中心的平等服務，除了采用固定容量、主動的隊列外，系統(tǒng)還設計了一系列其他控制策略。

由于數(shù)據(jù)分發(fā)中心對用戶是透明的，所以隊列在獲取分發(fā)任務時，對每個板塊中心平等對待。在控制隊列容量和板塊中心數(shù)量相等時，如果板塊中心均有分發(fā)請求，則每個板塊中心均有一條正在執(zhí)行的分發(fā)任務，如果存在某個板塊中心沒有分發(fā)請求，則進行下一個板塊中心的分發(fā)任務，即控制隊列獲取等待分發(fā)任務時，針對所有板塊中心進行輪詢，同時不浪費空間資源，保證每個中心得到均勻的任務響應。

在傳輸過程中系統(tǒng)可能出現(xiàn)無法控制的未知異常或錯誤，如網(wǎng)絡中斷、數(shù)據(jù)庫系統(tǒng)或某個推送站點意外宕機等，此時協(xié)同子系統(tǒng)無法得到失敗消息，會導致分發(fā)任務無法按照正常的流程執(zhí)行完畢而一直占用隊列資源，進而影響后續(xù)分發(fā)任務的執(zhí)行，因此隊列提供定時檢測機制，對長時間沒有結束的任務進行強制移除。

數(shù)據(jù)傳輸量大，防止用戶惡意提交大批量任務占用系統(tǒng)資源，板塊中心對每個用戶每天數(shù)據(jù)下載量進行控制，同時數(shù)據(jù)分發(fā)中心對板塊中心每年數(shù)據(jù)下載量控制。

3 運行實例

協(xié)同子系統(tǒng)采用Java+Axis2技術開發(fā)，使用Hibernate操作任務庫，部署在Linux平臺下的Tomcat服務器中，以WebService服務的方式與板塊中心、磁盤陣列、推送站點進行消息通信。控制隊列作為協(xié)同子系統(tǒng)的核心功能，在協(xié)同子系統(tǒng)啟動時開始執(zhí)行隊列控制流程，貫穿系統(tǒng)整個運行期間，保證數(shù)據(jù)的有序、高效分發(fā)。在實際運行環(huán)境中，板塊中心為6個，網(wǎng)絡為千兆網(wǎng)，設置控制隊列容量為6，可以保證對板塊中心的平均分配，若網(wǎng)絡環(huán)境不允許可適當調低隊列容量大小。策略上間隔5分鐘對隊列任務執(zhí)行一次超時檢測，經(jīng)測試最終設置超時閾值為30分鐘。

控制隊列沒有可視化運行界面，但可以通過即時監(jiān)控其執(zhí)行日志獲得隊列的控制流程及運行情況，如圖3所示。可以看到，系統(tǒng)在11月4日14：12沒有分發(fā)任務，控制隊列進入“取出wait”狀態(tài)，在11月4日20：33進入“加入wait”狀態(tài)，在11月4日20：34取消“加入wait”狀態(tài)的消息到來，在11月4日20：35再次進入“加入wait”狀態(tài)，在11月4日20：36進行了一次超時檢測。控制隊列執(zhí)行過程中對分發(fā)任務的狀態(tài)進行更新，用戶可以通過在板塊中心查看操作歷史記錄獲得分發(fā)任務的即時執(zhí)行狀態(tài)，如圖4所示。

4 結束語

本文闡述了一種基于SOA架構的數(shù)據(jù)分發(fā)系統(tǒng)結構，并針對系統(tǒng)中影像文件大、占用資源嚴重等特點，提出基于固定容量大小的單隊列控制模式解決方案，通過控制分發(fā)流程及控制策略，保證系統(tǒng)的性能及數(shù)據(jù)的傳輸質量，實現(xiàn)遙感影像數(shù)據(jù)的有序、規(guī)范、高效共享，滿足多用戶多行對遙感影像的獲取需求。

在實際運行測試環(huán)境中，單隊列控制模式穩(wěn)定可靠地完成了數(shù)據(jù)的分發(fā)任務，但同時也發(fā)現(xiàn)該解決方案的不足，即沒有實現(xiàn)任務優(yōu)先級的設計，無法滿足系統(tǒng)對應急分發(fā)任務及時優(yōu)先處理的需要，對此，我們將在后續(xù)的工作中進一步研究與完善。

參考文獻：

[1] 埃克爾（美）著，陳昊鵬譯.Java編程思想[M].機械工業(yè)出版社，2007.

[2] 盧傳富，蔡志明，夏學知.數(shù)據(jù)分發(fā)服務體系結構的研究[J].計算機與數(shù)字工程，2008.36（5）：67-69，82

[3] 黃飛龍.分布式計算中多隊列線程池的設計與實現(xiàn)[J].科協(xié)論壇，2013.4：95-98

[4] 徐建，李善平.用戶公平的活動隊列管理[J].電子學報，2004.32（3）：435-440

[5] 倪志偉.基于排隊論的訂單處理系統(tǒng)建模與仿真[D].北京交通大學，2009.

[6] 李男，黃永忠，郭紹忠.基于多隊列思想的作業(yè)處理環(huán)境的設計[J].計算機應用，2008.28：116-119

[7] 孟憲福.分布式環(huán)境下任務調度模型研究[J].大連理工大學學報，2006.46（6）：920-925

[8] 蘭秀菊，湯洪濤，陳勇.訂單處理過程的響應性分析[J].浙江工業(yè)大學學報，2006.34（1）：74-77