崔曉佳，張?jiān)疲瑒㈠\鋒

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

0 引言

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

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

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

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

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

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

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

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

圖2 原系統(tǒng)業(yè)務(wù)拓?fù)浣Y(jié)構(gòu)圖

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

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

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

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

1 設(shè)計(jì)思路

1.1 管家模式拓?fù)浣Y(jié)構(gòu)

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

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

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

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

圖3 管家模式拓?fù)浣Y(jié)構(gòu)

1.2 管家協(xié)議特性

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

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

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

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

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

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

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

1.3 管家協(xié)議格式

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

（1）請(qǐng)求與響應(yīng)

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

表1 請(qǐng)求消息

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

表2 響應(yīng)消息

（2）注冊(cè)、心跳與斷線

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

表3 注冊(cè)消息

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

表4 心跳消息

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

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

表5 斷線消息

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

2.1 協(xié)議流程分析

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

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

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

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

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

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

2.2 資源開銷分析

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

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

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

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

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

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

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

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

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

3 結(jié)語

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