如何利用Websphere MQ实现大文件交换

  • 格式:doc
  • 大小:615.00 KB
  • 文档页数:20

本文介绍了如何利用Websphere MQ提供的机制,实现大文件断点续传,从而可以在低速网络的情况下,不会因为网络的故障而使整个大文件重新传输。

本文介绍的这个实现可以大大的提高业务处理效率,并且可以对本文提供的思路进行扩展以完成更加复杂的功能。

1引言在低速的网络环境中,上传或者下载一个大文件需要花费很长的时间并且网络出现故障的机率很高。

如果网络出现故障的话,这个传输将会从头开始;如果经常出现网络故障的话,大文件的传输可能永远不会成功。

为了解决这个问题,实现断点续传功能的软件产品由此产生,比较著名的有网络蚂蚁,迅雷,BT,电驴。

Websphere MQ是一种消息中间件,Websphere MQ Server与Websphere MQ Server之间的数据传输实现了断点续传的功能,从而保障了传输的可靠性。

但是Websphere MQ 客户端应用与Websphere MQ Server之间没有提供断点续传的功能。

并且在很多的应用场合,Websphere MQ 客户端应用是通过低速网络与Websphere MQ Server通讯以完成数据的传输;所以我们需要实现一个机制来实现Websphere MQ客户端应用与Websphere MQ Server之间的断点续传,并且提供简单的应用编程接口来给第三方使用。

采用Websphere MQ来实现断点续传的功能的话,还可以利用Websphere MQ提供的加密机制来保障传输的安全性,以及在HTTP协议上传输以穿透防火墙等功能,从而使我们的断点续传功能更加具有竞争性。

2 术语定义Websphere MQ数据交换网络:表示多个Websphere MQ队列管理器进行配置形成一个完整的数据交换环境。

Websphere MQ 客户端应用:表示与Websphere MQ进行交互的应用程序。

MQ Client App: Websphere MQ 客户端应用的英文简称。

IBM Content Manager V8:IBM提供的一个内容管理平台。

3 Websphere MQ大文件交换应用架构在利用Websphere MQ实现大文件传输的应用系统中,存在以下几种架构。

3.1 单个Websphere MQ Server在只有一个Websphere MQ Server的也存在两种架构,分别如下所示:图3.1.1 断点传输应用架构一这张架构图描述了Websphere MQ 客户端断点上传应用、Websphere MQ Server、MQ Websphere MQ 客户端断点下载应用分别部署在不同的机器上进行文件的交换工作。

图3.1.1 断点传输应用架构二这张架构图描述了Websphere MQ 客户端断点上传应用部署在一台机器上而Websphere MQ Server和Websphere MQ 客户端断点下载应用在同一台机器上进行文件的交换工作。

3.2 多个Websphere MQ Server图3.2.1 断点传输应用架构三这张架构图描述了在整个系统中存在多个Websphere MQ队列管理器,这些队列管理器形成一个完整的Websphere MQ数据交换网络,而Websphere MQ 客户端断点上传应用、Websphere MQ 客户端断点下载应用分别部署于网络中任意一台机器上。

图3.2.2 断点传输应用架构四这张架构图描述了在整个系统中存在多个Websphere MQ队列管理器,这些队列管理器形成一个完整的Websphere MQ数据交换网络,而Websphere MQ 客户端断点上传应用、Websphere MQ 客户端断点下载应用分别部署于网络中任意一台机器上。

4功能对于大文件传输的应用,我们主要实现以下表格所示的功能。

1、单个大文件传输Websphere MQ 客户端断点上传应用把本机存在的一个大文件断点上传到Websphere MQ Server中。

Websphere MQ 客户端断点下载应用把存储在Websphere MQ中的大文件断点下载到本地,并且可以根据需求把这个大文件存储到IBM Content Manager V8中。

而传输大文件的这个功能点又可以细分为两个小的功能点:●Websphere MQ 客户端断点上传应用上传的大文件没有确定的接收者,这样的话任何的Websphere MQ 客户端断点下载应用都可以把存放在Websphere MQ Server中的这个大文件下载到本地。

●Websphere MQ 客户端断点上传应用上传的大文件有确定的接收者,这样的话只有按照某个用户登陆进入的Websphere MQ 客户端断点下载应用才可以从Websphere MQ Server断点下载此大文件到本地。

2、目录传输Websphere MQ 客户端断点上传应用把本机存在的一个目录断点上传到Websphere MQ Server中。

Websphere MQ 客户端断点下载应用把存储在Websphere MQ中的目录断点下载到本地,并且可以根据需求把这个目录存储到IBM Content Manager V8中。

这个功能其实是在单个大文件传输这个功能点的基础上进行更高一层的抽象。

这个功能点如同单个大文件传输一样可以细分成两个功能点:●Websphere MQ 客户端断点上传应用上传的目录没有确定的接收者,这样的话任何的Websphere MQ 客户端断点下载应用都可以把存放在Websphere MQ Server中的这个目录下载到本地。

●Websphere MQ 客户端断点上传应用上传的目录有确定的接收者,这样的话只有按照某个用户登陆进入的Websphere MQ 客户端断点下载应用才可以从WebsphereMQ Server断点下载此目录到本地3、分块传输这个功能点主要是针对在传输很大文件(如2G的文件)的时候,如果仅仅建立一个网络连接的话,相应的环境会限制这个网络连接最大的传输速度。

所以为了尽快地提高传输速度,需要启动多个线程以建立多个网络连接,每个线程传输大文件中的某段数据来实现并行上传和下载,这个功能点如同网络蚂蚁中多线程下载的功能。

4、调用用户自定义处理程序这个功能点主要对应的是这样的一种情况, Websphere MQ 客户端断点下载应用从Websphere MQ 中下载下来相应的大文件和目录后,需要对这些文件数据进行处理,然而对这些文件数据的处理逻辑程序是和用户的需求密切相关的,如处理逻辑程序就是完成把下载下来的大文件和目录装载到IBM Content Manager V8中。

这样的话就需要系统提供一种能够调用用户自定义开发的处理逻辑程序的能力,从而可以扩展此系统的功能。

5、系统纠错机制在现实情况下传输中会出现以下几种情况:1、网络中断:出现这种情况,传输将中断。

这样的话就需要系统提供一种机制从失败的那一点开始传输。

也就是说应用如果重新调用这个传输接口,传输将会从失败的那一点继续传输,而不是从开始传输。

2、客户端应用进程突然死掉:出现这种情况,传输将中断。

并且在应用进程中保存的一些信息将丢失,这样的话就需要传输接口提供一种信息持久化机制把相应的信息持久化到本地硬盘中(如果本地硬盘损坏的话,系统将还是从头开始传输),然后应用进程重新启动,传输将从失败的那一点继续传输。

当然这一点的实现可能会导致一些性能的损耗。

3、Websphere MQ Server进程突然死掉:Websphere MQ Server提供了持久话机制,如果利用了MQ Server的持久化机制,Websphere MQ Server重新启动后;传输将从失败的那一点继续传输。

如果没有,则传输将还是从头开始。

我们必需实现相应地机制,来对这些情况进行相应地纠错处理。

5 实现5.1 消息设计为了实现断点续传功能,在上传的时候我们需要把一个大文件进行拆分,形成大量的消息并把这些消息放入Websphere MQ中从而实现断点上传,在下载的时候我们从Websphere MQ 中取出相应的消息并进行组装形成相应的大文件从而实现断点下载。

我们需要对文件进行拆分成多个消息,这样我们就需要对这个消息所包含的内容进行设计,程序根据这些消息格式和程序代码本身的控制逻辑来实现可靠地传输。

5.1.1 文件传输控制消息(FileTransControlMsg)在传输大文件的时候,我们采用把文件进行分段(如每段的大小为4K,当然这个是一个可以进行配置的选项)的机制,为了实现这种机制我们需要一个控制消息来进行相应地控制。

这个控制消息将存放在FileTrans.Control 这个Websphere MQ队列中。

每传送一个文件只会在这个队列中产生一条消息。

在java/c++的实现中的类名为:FileTransControlMsg.5.1.2 文件传输数据消息(FileTransDataMsg)这个消息将存放在按照FileTransControlMsg这个消息结构中定义的QueueName字段对应的队列中,通过这种方式可以实现按照用户的需要把相应的消息放在所设定的队列中。

在java/c++的实现中的类名为:FileTransDataMsg.格式定义:5.1.3 上传完成控制消息(SendFinishControlMsg)当上传应用完成消息的断点上传的时候,将发送一个上传完成控制消息(SendFinishControlMsg)到队列FileTrans.Control.Finish中,下载应用可以从Websphere MQ队列中获取能够下载的文件列表,从而完成组装成一个大文件以供后续处理(如装载到IBM Content Manager V8中等)。

在java/c++的实现中的类名为:SendFinishControlMsg.5.2数据结构设计此数据结构设计的目地在于让程序能够完成相应的纠错机制(如网络纠错、程序异常终止等情况的纠错)。

这些数据结构对应的信息根据相应地配置文件的设定,以决定是否持久化到硬盘中。

5.2.1 上传文件控制结构(SendFileContorl)此结构描述了上传应用在发送文件的时候相应的进度信息。

在java/c++的实现中的类名为:SendFileContorl.这个结构将按照配置文件的需要被持久化到文件系统中(持久化的文件名称:ID字段的值.IBMMQ)5.2.2下载文件控制结构(RecvFileControl)5.3控制流程逻辑设计这个主要阐述了此程序内部实现的大致流程。

图5.3.1 系统大致流程图5.3.1初始化流程对应的方法:Init。

Step1、读取相应地配置文件,初始化相应地信息,完成如下之类的工作, 是否对多大的文件启动分块传输(并且分成多少块并发的开始传输)●是否启用MQ 消息持久化机制●是否启用程序控制信息(SendFileContorl信息)的持久化机制。