基于ZeroMQ的教学资源存储系统的设计

崔晓佳，张云，刘锦锋

（陆军工程大学石家庄校区无人机工程系，石家庄 050003）

0 引言

在教学资源存储系统、文件同步的功能，用户上传文件到服务器上后，出于对教学资源存储系统的安全性考虑，需要对文件进行病毒扫描、类型过滤、水印检查、内容检查等动作：

（1）类型过滤：教学资源存储系统仅允许Office文件、MPEG、JPG多媒体文件的上传；系统将根据文件内容的特征值进行类型判定，不符合要求的类型将被禁止；

（2）内容检查：对于文本类型文件，首先需要对文本内容的提取，然后对内容进行黑名单过滤，如不允许包含“涉密、绝密”字样；

（3）水印检查：教务系统要求对上传文件必须添加水印，系统将检查数字水印是否与上传者身份匹配，保证所有文件是可溯源的；

（4）病毒扫描：检查文件中是否包含恶意病毒。

业务流程如图1所示。

原业务系统采用每个连接分配一个子进程处理的方式，如图2所示，当业务量少的时候进程少，但随着业务访问增加，系统的资源是线性增长的。并且安全检查属于CPU密集型的处理，CPU处理能力是有限的，当进程数大于CPU核数后，如100并发、500并发、1000并发下，总体实际处理速度并不能变快，反而会导致业务系统假死的情况。

图1 教学资源存储系统流程图

图2 原系统业务拓扑结构图

本文设计了一种分布式通信的处理方法[1]，主要解决以下问题：

（1）各个处理子系统异构通信问题：类型检查、内容检查、水印检查、病毒扫描子系统功能相对独立，使用了不同的语言进行实现；但在教学资源系统中又需要统一调用，服务器接收到一系列文件之后，进行链式地安全检查处理，成功后才对文件进行入库；

（2）并行计算处理的问题：在教学资源存储系统中，安全检查为CPU密集型计算，如果采用顺序处理（文件接收、安全检查），并不能合理使用CPU资源，如果安全检查处理为多进程多个服务的处理模式，并行地进行文件接收、安全检查，能够合理利用服务器的CPU资源；

（3）集中统一调度的问题：如果不限制安全检查的服务数量，任由动态管理，则对于系统压力大的情况，服务数量远高于CPU核数，不仅所有CPU核满转，而且内存资源使用线性增长；若对于各个服务采用进行统一集中调度策略，启用固定数量的安全服务，就能够既在普通压力下并行处理，也能够在高压力下保证了资源分配问题。

1 设计思路

1.1 管家模式拓扑结构

管家模式是一种经典的分布式调度方法[2]，拓扑结构如图3所示，针对教学资源存储系统，可以在业务系统上划分为请求客户端、调度管家端、工作服务端三种角色：

（1）对于请求客户端角色（接收进程），主要负责网络I/O的处理，将客户端的文件接收保存到本地，接下来对调度进程发起服务请求，请求安全检查服务（内容检测、类型监测、水印监测、病毒监测）。请求客户端仅需要知道需要对文件进行哪种服务类型，仅关系处理的结果，不关心检测的过程；

（2）对于调度管家端角色（调度进程），则负责接收客户端请求、调用可用的工作服务端进行任务分配。每个工作服务端都在管家进行注册、分组统一管理。客户端发起新的请求后，管家将根据“先到先服务”的原则进行任务分配；

（3）对于工作服务端角色（工作进程），则专注于处理安全检测工作，对于管家分配的任务进行处理，处理后对结果进行返回。

图3 管家模式拓扑结构

1.2 管家协议特性

在本文的教学资源存储系统中，定义了一组请求客户端、一个调度管家端和一组工作服务端进行协同工作，使用了一个可靠的面向服务的请求-应答协议，称为管家协议（MDP）。

管家协议具备以下几个特性：

（1）工作服务端根据服务的类型可以分为：病毒检测、文本检测、水印检测、类型检测四种类型；每种类型服务可以启动若干个固定的工作子进程进行处理；

（2）每个工作进程都将在调度端进行注册，调度管家端将根据“服务类型”对工作应用进行分类，后续对每个工作进程的状态（空闲中、工作中）进行管理；

（3）请求客户端发起请求后，调度管家端将根据请求端请求的“服务类型”调度相应的、空闲的工作进程去处理请求；管家调度进程任务分配按照“最近最少使用（LRU）”的原则，保证每个工作应用都能合理获取到任务；

（4）调度管家进程与工作进程直接使用“保活心跳”机制来探测对方状态是否正常，对于不正常的工作应用进行剔除操作；

（5）各个应用遵循“允许随时重启”原则，保证业务能够在错误中快速恢复。层消息，如文件名、处理结果信息等。

1.3 管家协议格式

ZeroMQ提供了消息信封的方式，通过多帧拼装对消息进行描述[3]；管家协议的消息体采用4个消息帧组成，Frame1、Frame2一般为目的端、来源端唯一标识号（UUID），调度管家端通过UUID进行路由寻址，根据Frame1的UUID将消息信封转发给目的端；Frame3为消息类型：请求、响应、注册、心跳、断线；Frame4为应用

（1）请求与响应

请求消息如表1所示，由请求客户端发起，调度管家端收到Request消息后，根据“服务类型”查询到工作服务端的UUID，填充到Frame2进行下一步转发给相应的服务处理。

表1 请求消息

工作服务端每次最多只能处理一个请求，如表2所示，每次处理完成后都会发出一个响应报文；调度管家收到Response消息后，根据Frame1的UUID转发给相应的客户端。

表2 响应消息

（2）注册、心跳与断线

请求消息由工作服务端启动时发起，调度管家端收到Register消息后，根据“服务类型”进行分类，加入到LRU队列中，如表3所示。

表3 注册消息

如表4所示，心跳消息用于标识管家端、服务端中间的链接健康情况；管家端在LRU队列中维护了服务端的最近活跃时间，定时遍历所有LRU队列中空闲的工作服务，发送心跳消息告诉调度管家工作正常。

表4 心跳消息

同样的，空闲下来的服务端也定期向管家端发送心跳，Frame1、Frame2则为服务端 UUID、管家端UUID；如果服务端一段时间内收不到心跳消息，则将重新启动新的会话；

最终，一旦调度端发现服务端最近不再活跃，则标识为不可用服务，发送掉线消息，并从LRU队列剔除，如表5所示；

表5 断线消息

2 系统测试与分析

2.1 协议流程分析

从实现的协议角度上分析，原系统采用同步消息处理模式，如图4所示，客户端上传一批文件，必须挨个进行安全检查成功后才处理下一个；

改进后的系统采用异步的消息处理模式，客户端上传一批文件，如图5所示，服务器进行批量安全检查，整体处理结果比原有方式快；

图4 原系统协议流程

图5 改进后系统协议流程

从客户端、服务端通讯协议上分析，同步的消息处理，客户端必须等待服务端进行安全检查反馈后再发送下一个文件；发送、接收文件占用的I/O资源、安全检查占用的CPU资源，所以，服务端的I/O资源、CPU资源并没有充分调用起来，导致就算单一客户端程序上传一批文件时，也将耗费长时间等待；

改进的异步的处理能够将I/O资源、CPU资源进行充分利用起来，上传一批文件时，系统优先进行I/O处理（网络处理、磁盘处理），从第一个文件接收完成开始启动安全检查（CPU处理），每处理完成一个文件后再给客户端进行回复。

2.2 资源开销分析

在教学资源存储系统使用的高峰时期，原有方案使用动态分配机制，使用上限并无限制，经常出现服务器无响应的情况。

现有使用管家调度方法改进后，计算资源分配调整为固定的分配、调度方法，工作进程的数量是固定的；所以不论高峰时段、低峰时段，都占用固定的计算资源；

通过多核平台（Lin..10.25系统、英特尔四核E5320）进行仿真，如图6、7、8所示，分别对每一类服务模拟1～16个工作子进程，对应请求客户端的10、100、1000次请求的处理耗时的统计。

实验过程对于每个处理步骤都按照10ms进行模拟，每个文件经过类型检查、内容检查、水印检查、病毒扫描4个安全检查，总耗时为40ms；

根据数据分析，客户端为同步请求时，所需时间开销与服务进程数量无关。10、100、1000次请求分别稳定开.00ms、4000ms、40000ms左右；

客户端使用异步请求管家协议调度时，所需耗时随进程数的增加而有所减少。每类服务启动1个工作进程时，相比同步请求的处理速度是快了4倍，10、100、1000次请求分别稳定开销在100ms、1000ms、10000ms左右；当每类服务启动2个工作进程时，速度进一步提高。但当进程数达到一定数量后，并行计算所改善的效果不再明显，具体与硬件CPU核数、计算能力上限有关。

.0次请求结果图

.00次请求结果图

.000次请求结果图

3 结语

教学资源存储系统使用基于ZeroMQ的管家协议的分布式处理方案后，对于文件处理的速度具有明显提高。同时在教学高峰期时段，也能稳定处理多个部门同时进行文件上传。