利用MQ实现大文件交换

本文介绍了如何利用ActiveMQ提供的机制，实现大文件断点续传，从而可以在低速网络的情况下，不会因为网络的故障而使整个大文件重新传输。本文介绍的这个实现可以大大的提高业务处理效率，并且可以对本文提供的思路进行扩展以完成更加复杂的功能。

1引言

在低速的网络环境中，上传或者下载一个大文件需要花费很长的时间并且网络出现故障的机率很高。如果网络出现故障的话，这个传输将会从头开始；如果经常出现网络故障的话，大文件的传输可能永远不会成功。为了解决这个问题，实现断点续传功能的软件产品由此产生，比较著名的有Flashget，迅雷，BT，电驴。
ActiveMQ是Apache旗下开放源代码的消息中间件，消息中间件作为一个基础传输中间件已经问世好多年的历史了，他主要应用于分布式系统中，在分布式系统中，存在着许多异构环境、不同的开发语言和不同的传输协议，所以要实现这些系统之间的通信是一个相当复杂的工程。消息中间件的问世就是为了解决这些问题，把这些问题从应用中分离出来，形成一个专门的底层系统软件，使分布式环境对我们应用开发人员来说是透明的。可靠性传输可以说是消息中间件的立足之本，对于应用来说，只要成功把数据提交给消息中间件，那么它能够保障数据在复杂的网络中高效、稳定、安全、可靠的传输，并确保传输的数据不错、不重、不漏、不丢。
采用ActiveMQ来实现断点续传的功能的话，还可以利用ActiveMQMQ提供的加密机制来保障传输的安全性，以及在HTTP协议上传输以穿透防火墙等功能,从而使我们的断点续传功能更加具有竞争性。

2 术语定义

Message Broker：消息服务器
JMS Streams：JMS流对象。
Blob Messages: Binary Large Object Messages的英文简称，即二级制大对象消息。

3 ActiveMQ大文件交换应用架构

在利用ActiveMQ实现大文件传输的应用系统中，存在以下几种架构。

3.1 通过JMS Streams进行文件传输

通过JMS的StreamMessage或者BytesMessage传输文件的时候，必须一次将整个文件全部加载到内存当中，这种发送文件效率低下而且需要占用大量的内存资源，如果一旦文件比内存大的话，将无法提供服务。
通过JMS Streams，花费较小的内存就可以传输比内存空间还大的文件，其结构如下图所示：

图3.1.1 通过JMS streams传输文件
发送方代码片段：
ActiveMQConnection connection = ...;
Destination destination = new ActiveMQQueue("sdo.amo.fileTransfer");
OutputStream out = connection.createOutputStream(destination);
// write the file to out
out.close();
接收方代码片段：
ActiveMQConnection connection = ...;
Destination destination = new ActiveMQQueue("sdo.amo.fileTransfer");
InputStream in = connection.createInputStream(destination)
// read the stream...
in.close();
但是通过JMS Streams传输文件也存在一些不足之处：

1. 文件发送端与文件接收端必须同时在线；
2. 不支持断点续传，可靠性较差；
3. 不支持发布订阅模式。

3.2 通过文件分割/合并传输文件

这种方式充分的运用了MQ在网络条件比较差时能够可靠传递消息的优点，为了实现断点续传功能，在上传的时候我们需要把一个大文件进行分割，形成大量的消息并把这些消息放入ActiveMQ中从而实现断点上传，在下载的时候我们从ActiveMQ中取出相应的消息并进行合并形成相应的大文件从而实现断点下载。
在传输大文件的时候，我们采用把文件进行分割（如每段的大小为4K，当然这个是一个可以进行配置的选项）的机制，为了实现这种机制我们需要一个控制消息来进行相应地控制。我们通过ActionMQ的Group Message可以很容易的做到，就是在创建消息的时候设置JMSXGroupID、JMSXGroupSeq以及ChunkCount等，以便于文件接收端收到消息后能够很容易的合并。
这种方式完全是通过JMS的特性来实现的，其缺点就是文件合并的复杂度会随着传输文件的大小的增加而增加。当传输的文件很大时，ActiveMQ就需要传送大量的消息，在网络条件不是很好的情况下，消息收到的顺序与发送的顺序并不是一致的，因此合并文件会相对比较复杂。

3.3 通过Blob Messages传输文件

由于JMS Streams的种种不足，限制了其用于传输大文件的功能。因此，ActiveMQ在JMS的基础上创建了一种新的消息类型------BlobMessage。
因为派生与JMS的Message对象，通过BlobMessage传输大文件可以利用ActiveMQ消息Broker的所有特性，如高可靠性、事务支持、发布订阅......
Blob Messages是通过带外传输（out-of-band transport）的机制来实现大文件传输的，在文件传输的过程中，通过http、ftp、scp或其他点对点的协议来进行文件的传输，同时，通过BlobMessage来传送控制信息以及文件的验证信息。其结构图如下：

图3.2.2 通过Blob Messages传输文件
由于JMS可以可靠的将控制信息传送到ActiveMQ Broker，同时ftp协议本身就支持断点续传，所以，文件简单的就可以发送到服务端，并且保存在服务端，当文件的消费端监听队列的队列就可以轻松的下载文件了，如果存在多个消费端，则可以通过JMS的发布订阅模式实现。
通过比较三种方案，第一种通过JMS Streams传输存在断点续传的问题，第二种方式则引入了额外的复杂度------分割文件和合并文件，复杂度相对较高，第三种Blob Messages对于开发者来说就和发送普通消息是一样的，只是服务端它依赖FTP Server来上传下载文件。经过比较可以发现，Blob Messages的方式更具备可用性。

功能

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

功能点	功能子点
大文件传输	没有确定的接收者
	有确定的一个接收者
	有确定的多个接收者
分块传输	多线程并发分快传输
系统纠错机制	网络中断纠错机制
	客户端应用进程突然死掉纠错机制
	MQ Server进程突然死掉纠错机制

表格4.1 功能列表