集群内高效可靠的数据文件分发方案的设计

杨永凯，彭明田，王炜东

(1.中国民航信息网络股份有限公司，北京 101318；2.民航旅客服务智能化应用技术重点实验室，北京 101318)

0 引 言

在信息化工程领域，经常需要面对局域网集群内一对多模式下的数据文件分发问题，即从一台生产者主机向集群内若干台订阅者主机进行数据文件的分发传输。以民航信息化行业为例：航班的舱位状态报文(SSIM报)是一种高频的数据文件，全球所有航班的任何一次舱位变化(销售、取消、控制等)均会触发SSIM报文；而全球的民航运价数据在经过预处理后会形成大体量的数据文件，部分文件压缩后仍达到几十G左右，这种数据文件在以约每小时一次的频率更新变化。在民航工程应用中，需要将这两类数据文件从生产者主机高效准确地分发到集群中数十甚至上百台订阅者主机上，进而在订阅者主机(即计算节点)上实现高性能的可用机票搜索计算服务。在局域网集群内的数据分发方案设计方面，高效和可靠往往意味着系统优化的两个不同方向：FTP、HTTP等基于TCP协议实现的通信协议，可以实现准确可靠的数据传输，但是TCP协议只能支持一对一(端到端)的传输模式，在生产/订阅这种一对多模式下，意味着必须重复多次传输，占用大量的网络带宽资源，无法实现高效的目的；而UDP协议可以实现一对多的数据传输，能够大幅节省网络带宽资源，但是由于UDP协议本身是轻量级的无连接协议，无法保障传输的准确可靠性。在工程实践中，基于开源架构的消息中间件ZeroMQ和自行设计的控制逻辑构建了一套以UDP传输为主，辅以TCP协议进行控制的集群内高效可靠的多播数据文件分发方案，成功解决了高频报文或者大体量数据文件的一对多数据分发问题[1-5]。

1 ZeroMQ简介

ZeroMQ不是单独的服务或者程序，仅仅是一套组件，其封装了网络通信、消息队列、线程调度等功能，向上层提供简洁的API，应用程序通过加载库文件，调用API函数来实现高性能网络通信。由于ZeroMQ是用C/C++开发地，并且其协议格式定义得很简单，所以它的性能远远高于其他消息队列中间件。

ZeroMQ提供了4种基础消息通讯模式，分别是一对一结对模式(Exclusive-Pair)、请求应答模式(Request-Reply)、发布订阅模式(Publish-Subscribe)和推拉模式(Push-Pull)。这4种模式总结出了通用的网络通信模型，使用者可以根据具体应用场景，使用其中的任何一种或多种模式，构建自己的通讯架构解决方案。文中方案所涉及的主要是发布订阅模式。

ZeroMQ的发布订阅模式封装了UDP通信协议的实现细节，简化了系统设计和编程实现的开发工作，基于ZeroMQ组件可以简单快捷地实现基于UDP协议的高效的多播数据分发。在ZeroMQ的发布订阅模式下，发布端负责单向分发数据，且不关心是否把全部数据发送给订阅端。如果发布端开始发布数据时，订阅端尚未连接上来，则这些数据会被直接丢弃。订阅端只负责接收数据，而不能反馈，且在订阅端处理速度慢于发布端处理速度的情况下，会在订阅端堆积数据。其结构如图1所示[6-7]。

图1 发布订阅模式

在工程实践中，除了需要考虑高效外，还要兼顾可靠性。为了保障数据文件分发传输的可靠性，必须在UDP多播的基础上增加控制流，以实现对多播分发的有效调度，从而避免丢包、乱序、不一致、数据堆积等方面的问题。控制流的实现必须通过可靠的TCP协议来自行设计实现。

2 系统设计

2.1 总体结构

系统在设计实现上采取了数据流和控制流相对分离的设计机制，系统整体结构如图2所示。数据流基于ZeroMQ包装的UDP协议实现，图中用实线箭头表示；控制流通过自主设计的基于TCP协议的控制机制实现，图中用虚线箭头表示。数据流和控制流结合达到数据文件分发过程中高效和可靠的目的。

图2 系统整体结构

将集群中负责数据文件分发的主机定义为Master主机，Master主机实现发布者Publisher的功能，将集群中接收数据文件的主机定义为Node主机，Node主机实现订阅者Subscriber的功能，Master和Node之间通过ZeroMQ的发布订阅模式实现多播数据的传输，从而构成数据流的设计。

控制流的设计主要由Master主机上的监控服务(Monitor)模块、调速服务(Shift)模块以及Node主机上的检测服务(Check)模块、计速服务(Meter)模块组成。Master主机上的Monitor服务与各Node主机上的Check服务配对实现针对数据流的传输开关控制，包括传输端口的控制(打开及关闭)以及数据流的启停等。Master主机上的Shift模块与各Node主机上的Meter模块配对实现针对数据流的传输速率控制，兼顾网络环境和Node节点的处理效率，保障Master主机以合适的速率在集群内分发数据文件。

另外在Master主机设计了Register服务模块，当有新的Node主机连接入集群时，其本地的Check服务首先与Master主机的Register服务建立TCP连接，将新加入的Node主机的信息注册到Master主机，从而达到新加入的Node主机实时参与数据流多播的目的。

为了保障数据文件的完整，在Node主机设计了File Slot模块，用来开辟缓存存储大体量数据文件和高频报文文件的多播数据包，待传输完成后，将相应数据文件存入Node主机的指定位置。

高效可靠的多播数据传输方案的设计核心是控制流和数据流的交互模式，重点体现在控制流对数据流的传输开关控制和传输速率控制两个方面。传输开关控制和传输速率控制的目的是在可接受的传输速率下，尽可能降低同一份文件的多播分发轮次，最理想的情况是Master主机执行一次多播传输即可完成所有Node主机的数据文件接收，从而实现传输效率的最大化[8-12]。

2.2 数据流的传输开关控制

传输开关控制的目的是确定一个文件是否成功完成了分发传输，即所有Node主机均接收到了该文件，并启动下一个新文件的分发传输。具体流程如下：当Master主机需要分发数据文件时，会通过Monitor服务告知各个Node主机节点的Check服务，随后Check服务会检查本地是否已经有Master主机所要分发的数据文件，如果没有则启用数据流的Subscriber服务，Subscriber服务打开相应的UDP端口，准备接收数据；如果有则不启用Subscriber服务，不打开相应的UDP端口。Node主机的Check服务会将最后的检查结果通过TCP连接告知Master主机，Master主机会检测所有Node主机的返回结果，判断集群中是否有节点需要接收当前的数据文件，如果有则启用本地的Publisher服务，Publisher服务会打开相应的UDP端口通过多播分发数据文件；如果没有则不启用Publisher服务，不进行当前数据文件的分发，也标志着Master主机已经完成了当前数据文件的分发。综上所述，Monitor服务的操作流程如图3所示，Check服务的操作流程如图4所示[10-11]。

图3 Monitor服务流程

图4 Check服务流程

2.3 数据流的传输速率控制

传输速率控制的目的是保障Master主机的数据传输速率能够和Node主机的数据处理速率适配，从而提升多播传输的一次成功率。根据集群网络的带宽情况和Master与Node主机的硬件情况，确定多播传输速率的上限和下限数值，在数据流传输过程中，传输速率始终保持在上限和下限区间内，这个速率区间可以定义为集群的高效多播区间。超过上限可能会频繁出现Node接收失败的问题，导致同一个数据文件的多轮次分发，低于下限可能导致多播传输速率过低，文件分发时间过长。

具体流程如下：Master主机的Shift服务读取Config配置信息，包括多播速率的上下限、初始速率等，之后将相关信息发送给Publisher服务和Node主机上的Meter服务；根据数据流的传输开关控制机制，在本轮次多播分发启动后，Publisher服务会按照初始速率通过多播分发数据，Node主机的Subscriber服务负责接收多播数据；如果在接收数据的过程中，Subscriber服务出现数据积压的情况会反馈给Meter服务，或者当监控到网络繁忙的情况后，Meter服务会主动和Master主机上的Shift服务通信，Shift服务会调整Publisher的多播速率以适应所有Node的处理速率；如果Shift服务将速率调整到速率下限后仍旧有Node主机反馈存在数据积压的情况，则通知相应Node主机的Meter服务停止接收本轮次多播分发，并提升整个集群多播传输速率；被停止的Node主机可以等待当前文件的下一轮次多播来完成文件接收，等待的过程同时也是该Node主机恢复数据处理的过程。传输速率控制的设计如图5所示[11-12]。

图5 传输速率控制的设计

3 系统实现和工程验证

基于上述数据流和控制流相结合的设计方案，在工程上进行了编码实现和实践验证，具体的开发环境和部署环境如表1所示。

表1 工程实践的应用环境

目前该套系统已经部署在生产环境，负责集群内大体量文件的分发和高频报文的分发任务。为了验证该方案针对大体量文件分发的有效性，任意截取了连续15天的文件分发数据作为15份样本进行方案验证，每1天的数据组成1份样本。在每天内的每个整点启动1个轮次多播分发，根据实际业务的更新情况，每轮次分发的数据文件总数在10至15个左右，最大的文件40 G左右，最小的10 M左右，每轮次需分发的文件总容量大约为90 G左右。

定义n次分发成功率参数分别为R1,R2,…,Rn：

如果R1越接近于1，且Rn越早收敛到1，则表明该方案的控制流有效性越高。对上述工程实践中样本的汇总如表2所示：R1的平均值为0.983 3，绝大多数样本R2即收敛为1，只有1个样本在R3收敛为1，另外每组样本的多播平均传输速率接近设定的上限100 Mib/s。从实际工程角度看，该方案的控制流有效性较高，可以满足实际项目的需求[13-15]。

表2 工程实践的验证结果

该方案同时还承担高频报文的分发任务，报文的大小基本在1至5K，非常适合于多播模式的传输，基于控制流的辅助，在生产集群中高频报文的分发成功率R1基本约等于1，不再赘述。

4 结束语

综上所述，该方案通过基于UDP多播的数据流和基于TCP协议的控制流相结合的方式，有效解决了集群内数据文件分发过程中的高效和可靠兼得的问题，即适用于集群内大体量的数据文件分发，又适用于集群内高频报文文件的分发，在工程实践中具有很重要的典型意义。