基于ZeroMQ的教學資源存儲系統(tǒng)的設(shè)計

崔曉佳，張云，劉錦鋒

（陸軍工程大學石家莊校區(qū)無人機工程系，石家莊 050003）

0 引言

在教學資源存儲系統(tǒng)、文件同步的功能，用戶上傳文件到服務器上后，出于對教學資源存儲系統(tǒng)的安全性考慮，需要對文件進行病毒掃描、類型過濾、水印檢查、內(nèi)容檢查等動作：

（1）類型過濾：教學資源存儲系統(tǒng)僅允許Office文件、MPEG、JPG多媒體文件的上傳；系統(tǒng)將根據(jù)文件內(nèi)容的特征值進行類型判定，不符合要求的類型將被禁止；

（2）內(nèi)容檢查：對于文本類型文件，首先需要對文本內(nèi)容的提取，然后對內(nèi)容進行黑名單過濾，如不允許包含“涉密、絕密”字樣；

（3）水印檢查：教務系統(tǒng)要求對上傳文件必須添加水印，系統(tǒng)將檢查數(shù)字水印是否與上傳者身份匹配，保證所有文件是可溯源的；

（4）病毒掃描：檢查文件中是否包含惡意病毒。

業(yè)務流程如圖1所示。

原業(yè)務系統(tǒng)采用每個連接分配一個子進程處理的方式，如圖2所示，當業(yè)務量少的時候進程少，但隨著業(yè)務訪問增加，系統(tǒng)的資源是線性增長的。并且安全檢查屬于CPU密集型的處理，CPU處理能力是有限的，當進程數(shù)大于CPU核數(shù)后，如100并發(fā)、500并發(fā)、1000并發(fā)下，總體實際處理速度并不能變快，反而會導致業(yè)務系統(tǒng)假死的情況。

圖1 教學資源存儲系統(tǒng)流程圖

圖2 原系統(tǒng)業(yè)務拓撲結(jié)構(gòu)圖

本文設(shè)計了一種分布式通信的處理方法[1]，主要解決以下問題：

（1）各個處理子系統(tǒng)異構(gòu)通信問題：類型檢查、內(nèi)容檢查、水印檢查、病毒掃描子系統(tǒng)功能相對獨立，使用了不同的語言進行實現(xiàn)；但在教學資源系統(tǒng)中又需要統(tǒng)一調(diào)用，服務器接收到一系列文件之后，進行鏈式地安全檢查處理，成功后才對文件進行入庫；

（2）并行計算處理的問題：在教學資源存儲系統(tǒng)中，安全檢查為CPU密集型計算，如果采用順序處理（文件接收、安全檢查），并不能合理使用CPU資源，如果安全檢查處理為多進程多個服務的處理模式，并行地進行文件接收、安全檢查，能夠合理利用服務器的CPU資源；

（3）集中統(tǒng)一調(diào)度的問題：如果不限制安全檢查的服務數(shù)量，任由動態(tài)管理，則對于系統(tǒng)壓力大的情況，服務數(shù)量遠高于CPU核數(shù)，不僅所有CPU核滿轉(zhuǎn)，而且內(nèi)存資源使用線性增長；若對于各個服務采用進行統(tǒng)一集中調(diào)度策略，啟用固定數(shù)量的安全服務，就能夠既在普通壓力下并行處理，也能夠在高壓力下保證了資源分配問題。

1 設(shè)計思路

1.1 管家模式拓撲結(jié)構(gòu)

管家模式是一種經(jīng)典的分布式調(diào)度方法[2]，拓撲結(jié)構(gòu)如圖3所示，針對教學資源存儲系統(tǒng)，可以在業(yè)務系統(tǒng)上劃分為請求客戶端、調(diào)度管家端、工作服務端三種角色：

（1）對于請求客戶端角色（接收進程），主要負責網(wǎng)絡I/O的處理，將客戶端的文件接收保存到本地，接下來對調(diào)度進程發(fā)起服務請求，請求安全檢查服務（內(nèi)容檢測、類型監(jiān)測、水印監(jiān)測、病毒監(jiān)測）。請求客戶端僅需要知道需要對文件進行哪種服務類型，僅關(guān)系處理的結(jié)果，不關(guān)心檢測的過程；

（2）對于調(diào)度管家端角色（調(diào)度進程），則負責接收客戶端請求、調(diào)用可用的工作服務端進行任務分配。每個工作服務端都在管家進行注冊、分組統(tǒng)一管理。客戶端發(fā)起新的請求后，管家將根據(jù)“先到先服務”的原則進行任務分配；

（3）對于工作服務端角色（工作進程），則專注于處理安全檢測工作，對于管家分配的任務進行處理，處理后對結(jié)果進行返回。

圖3 管家模式拓撲結(jié)構(gòu)

1.2 管家協(xié)議特性

在本文的教學資源存儲系統(tǒng)中，定義了一組請求客戶端、一個調(diào)度管家端和一組工作服務端進行協(xié)同工作，使用了一個可靠的面向服務的請求-應答協(xié)議，稱為管家協(xié)議（MDP）。

管家協(xié)議具備以下幾個特性：

（1）工作服務端根據(jù)服務的類型可以分為：病毒檢測、文本檢測、水印檢測、類型檢測四種類型；每種類型服務可以啟動若干個固定的工作子進程進行處理；

（2）每個工作進程都將在調(diào)度端進行注冊，調(diào)度管家端將根據(jù)“服務類型”對工作應用進行分類，后續(xù)對每個工作進程的狀態(tài)（空閑中、工作中）進行管理；

（3）請求客戶端發(fā)起請求后，調(diào)度管家端將根據(jù)請求端請求的“服務類型”調(diào)度相應的、空閑的工作進程去處理請求；管家調(diào)度進程任務分配按照“最近最少使用（LRU）”的原則，保證每個工作應用都能合理獲取到任務；

（4）調(diào)度管家進程與工作進程直接使用“?；钚奶睓C制來探測對方狀態(tài)是否正常，對于不正常的工作應用進行剔除操作；

（5）各個應用遵循“允許隨時重啟”原則，保證業(yè)務能夠在錯誤中快速恢復。層消息，如文件名、處理結(jié)果信息等。

1.3 管家協(xié)議格式

ZeroMQ提供了消息信封的方式，通過多幀拼裝對消息進行描述[3]；管家協(xié)議的消息體采用4個消息幀組成，F(xiàn)rame1、Frame2一般為目的端、來源端唯一標識號（UUID），調(diào)度管家端通過UUID進行路由尋址，根據(jù)Frame1的UUID將消息信封轉(zhuǎn)發(fā)給目的端；Frame3為消息類型：請求、響應、注冊、心跳、斷線；Frame4為應用

（1）請求與響應

請求消息如表1所示，由請求客戶端發(fā)起，調(diào)度管家端收到Request消息后，根據(jù)“服務類型”查詢到工作服務端的UUID，填充到Frame2進行下一步轉(zhuǎn)發(fā)給相應的服務處理。

表1 請求消息

工作服務端每次最多只能處理一個請求，如表2所示，每次處理完成后都會發(fā)出一個響應報文；調(diào)度管家收到Response消息后，根據(jù)Frame1的UUID轉(zhuǎn)發(fā)給相應的客戶端。

表2 響應消息

（2）注冊、心跳與斷線

請求消息由工作服務端啟動時發(fā)起，調(diào)度管家端收到Register消息后，根據(jù)“服務類型”進行分類，加入到LRU隊列中，如表3所示。

表3 注冊消息

如表4所示，心跳消息用于標識管家端、服務端中間的鏈接健康情況；管家端在LRU隊列中維護了服務端的最近活躍時間，定時遍歷所有LRU隊列中空閑的工作服務，發(fā)送心跳消息告訴調(diào)度管家工作正常。

表4 心跳消息

同樣的，空閑下來的服務端也定期向管家端發(fā)送心跳，F(xiàn)rame1、Frame2則為服務端 UUID、管家端UUID；如果服務端一段時間內(nèi)收不到心跳消息，則將重新啟動新的會話；

最終，一旦調(diào)度端發(fā)現(xiàn)服務端最近不再活躍，則標識為不可用服務，發(fā)送掉線消息，并從LRU隊列剔除，如表5所示；

表5 斷線消息

2 系統(tǒng)測試與分析

2.1 協(xié)議流程分析

從實現(xiàn)的協(xié)議角度上分析，原系統(tǒng)采用同步消息處理模式，如圖4所示，客戶端上傳一批文件，必須挨個進行安全檢查成功后才處理下一個；

改進后的系統(tǒng)采用異步的消息處理模式，客戶端上傳一批文件，如圖5所示，服務器進行批量安全檢查，整體處理結(jié)果比原有方式快；

圖4 原系統(tǒng)協(xié)議流程

圖5 改進后系統(tǒng)協(xié)議流程

從客戶端、服務端通訊協(xié)議上分析，同步的消息處理，客戶端必須等待服務端進行安全檢查反饋后再發(fā)送下一個文件；發(fā)送、接收文件占用的I/O資源、安全檢查占用的CPU資源，所以，服務端的I/O資源、CPU資源并沒有充分調(diào)用起來，導致就算單一客戶端程序上傳一批文件時，也將耗費長時間等待；

改進的異步的處理能夠?qū)/O資源、CPU資源進行充分利用起來，上傳一批文件時，系統(tǒng)優(yōu)先進行I/O處理（網(wǎng)絡處理、磁盤處理），從第一個文件接收完成開始啟動安全檢查（CPU處理），每處理完成一個文件后再給客戶端進行回復。

2.2 資源開銷分析

在教學資源存儲系統(tǒng)使用的高峰時期，原有方案使用動態(tài)分配機制，使用上限并無限制，經(jīng)常出現(xiàn)服務器無響應的情況。

現(xiàn)有使用管家調(diào)度方法改進后，計算資源分配調(diào)整為固定的分配、調(diào)度方法，工作進程的數(shù)量是固定的；所以不論高峰時段、低峰時段，都占用固定的計算資源；

通過多核平臺（Lin..10.25系統(tǒng)、英特爾四核E5320）進行仿真，如圖6、7、8所示，分別對每一類服務模擬1～16個工作子進程，對應請求客戶端的10、100、1000次請求的處理耗時的統(tǒng)計。

實驗過程對于每個處理步驟都按照10ms進行模擬，每個文件經(jīng)過類型檢查、內(nèi)容檢查、水印檢查、病毒掃描4個安全檢查，總耗時為40ms；

根據(jù)數(shù)據(jù)分析，客戶端為同步請求時，所需時間開銷與服務進程數(shù)量無關(guān)。10、100、1000次請求分別穩(wěn)定開.00ms、4000ms、40000ms左右；

客戶端使用異步請求管家協(xié)議調(diào)度時，所需耗時隨進程數(shù)的增加而有所減少。每類服務啟動1個工作進程時，相比同步請求的處理速度是快了4倍，10、100、1000次請求分別穩(wěn)定開銷在100ms、1000ms、10000ms左右；當每類服務啟動2個工作進程時，速度進一步提高。但當進程數(shù)達到一定數(shù)量后，并行計算所改善的效果不再明顯，具體與硬件CPU核數(shù)、計算能力上限有關(guān)。

.0次請求結(jié)果圖

.00次請求結(jié)果圖

.000次請求結(jié)果圖

3 結(jié)語

教學資源存儲系統(tǒng)使用基于ZeroMQ的管家協(xié)議的分布式處理方案后，對于文件處理的速度具有明顯提高。同時在教學高峰期時段，也能穩(wěn)定處理多個部門同時進行文件上傳。