遙感數據分發系統單隊列控制模式的設計與實現

沈夏炯　張振鵬　段勝強

摘 要： 鑒于遙感單一影像文件大、總體數據海量的特點，針對如何保證遙感數據分發系統能有序、規范、高效地為各行業用戶提供共享數據問題，對遙感數據分

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

關鍵詞： 遙感數據； 分發； 隊列； 控制

中圖分類號：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 引言

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

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

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

1 系統總體框架結構

遙感數據分發系統采用SOA架構設計，各子系統之間通過WebService進行消息通信，其部署架構圖如圖1所示。

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

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

協同子系統負責與各個板塊中心、磁盤陣列和推送站點之間的消息通信，控制數據傳輸的流程，保證系統在網絡與系統資源有限的情況下高質量的數據分發，是整個系統的不可或缺的服務組件。協同子系統中的任務庫用來保存板塊中心信息、系統配置及數據分發過程產生的狀態信息等少量控制信息，任務控制隊列負責統一調度控制數據的分發，是整個系統的核心，也是本文討論的重點。

2 單隊列控制模式的設計

2.1 數據分發流程

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

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

⑵ 將需要得到的數據作為訂單提交至板塊中心，板塊中心調用數據分發中心協同子系統提供的提交訂單WebService服務，提交數據分發任務。

⑶ 協同子系統將收到的分發任務存放在任務庫中，等待控制隊列的調度執行，同時告知板塊中心任務提交成功處于等待處理狀態。

⑷ 執行分發任務時，協同子系統選擇推送站點將用戶請求的數據推送到用戶所屬的板塊中心。

⑸ 推送成功后，由協同子系統通知相應的板塊中心用戶可以取走數據。

⑹ 數據在分發過程中如果出錯即任務失敗，則由協同子系統告知板塊中心，允許用戶再次提交對該數據的獲取請求。

2.2 隊列控制流程設計

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

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

2.3 隊列控制流程描述

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

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

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

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

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

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

2.4 隊列控制策略設計

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

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

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

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

3 運行實例

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

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

4 結束語

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

在實際運行測試環境中，單隊列控制模式穩定可靠地完成了數據的分發任務，但同時也發現該解決方案的不足，即沒有實現任務優先級的設計，無法滿足系統對應急分發任務及時優先處理的需要，對此，我們將在后續的工作中進一步研究與完善。

參考文獻：

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

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

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

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

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

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

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

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