按照JMS规范,为了保证可靠性,所有的消息都应该是发送到broker,然后交由broker来投递的。也即是说其实JMS是不建议或不支持传输文件的。
对于比较小的文件,简单的处理方式是先读取所有的文件成byte[],然后使用ByteMessage,把文件数据发送到broker,像正常的message一样处理。对于大文件,例如1GB以上的文件,这么搞直接把client或是broker给oom掉了。
这种方式仅仅适用于小文件的传输。特别是如果broker端使用数据库作为存储,message序列化以后存放于blob字段,文件传输频繁或是稍微有点大,写入效率极低。
文件传输为了解决传输大文件的问题,ActiveMQ在jms规范之外引入了jms streams的概念。PTP模式下,连到同一个destination的两端,可以通过broker中转来传输大文件。
发送端使用connection.createOutputStream打开一个输出流,往流里写文件。
OutputStream out =connection.createOutputStream(destination);
接收端则简单的使用connection.createInputStream拿到一个输入流,从中读取文件数据即可。
InputStream in = connection.createInputStream(destination)详见:http://activemq.apache.org/jms-streams.html
使用非常简单。ActiveMQ在中间做了什么事情呢?
其实过程蛮曲折的,发送端拿到文件后,首先分片,默认64K文件数据为一个byte message,然后依次把所有的message发送到broker,broker转发给接收端,最后发送一个空消息作为结束符。
详情可参考图_1所示:
connection上提供了两个创建OutputStream的方法,一个是createOutputStream创建的是持久化的消息集合,这些数据会写到磁盘或是数据库(对大文件来说慢消费也是一件可怕的事儿);一个是createNonPersistOutputStream创建的是非持久化消息集合,不会写到磁盘上,如果没有及时消费掉就惨了。
文件片段的byte message的TTL设置为0,就是不会超时进入DLQ。
优势:简单直接,处理非常小(不大于64K)的文件非常方便。
劣势:对大文件,简直就是噩梦。
使用消息的方式来传递大文件,明显不是一个有效率的办法。文件应该就是按文件的方式去处理。
自己处理中转如果自己处理文件的话,一个简单方式是使用共享或ftp、dfs等方式,先把文件发送到一个大家都可以拿到的地方,然后发送 message,payload或properties中包含文件的路径信息。这样,consumer拿到文件路径后去指定的地方,按照给定的方式去获取文件数据即可。
优势:这种方式可以用来处理大数据,并且不需要client或broker在内存中持有文件数据本身,非常的节省资源。而且文件是通过额外的方式处理,跟ActiveMQ本身无关,所以符合jms协议、处理的效率也相对比较高。
劣势:需要自己处理很多文件相关的操作。
BlobMessage对文件中转的封装幸运的是,ActiveMQ把上面繁复的文件处理工作进行了封装,屏蔽掉文件中转的整个处理过程,使得我们可以使用类似jms规范的API来简单操作文件传输。
举个例子来说,典型的使用步骤:
发送端:
1. 启动ActiveMQ时,也启动jetty(即activemq.xml中有import jetty.xml),此时jetty中运行了一个ActiveMQ自带的http文件服务器
2. 使用tcp://localhost:61616?jms.blobTransferPolicy.defaultUploadUrl=http://localhost:8161/fileserver/创建connection,然后创建session和producer
3. 使用如下代码发送文件:
BlobMessageblobMessage = session.createBlobMessage(file);
blobMessage.setStringProperty("FILE.NAME",file.getName());
blobMessage.setLongProperty("FILE.SIZE",file.length());
producer.send(blobMessage);
接收端比较简单,正常的使用jms接收到消息:
InputStream inputStream = blobMessage.getInputStream();
然后直接读取文件数据即可。文件名和文件大小可以从message的属性中拿到。
这个过程中ActiveMQ做了什么呢?
发送端:producer.send的时候,把文件通过http协议的PUT方法发到jetty中的fileserver(默认128K走http的chunk分片传输)。然后把http的url写入消息中。再把消息发送到broker。
接收端:接收到消息以后,发现是BlobMessage,拿到url,直接使用GET方法获取文件数据。处理完毕后,使用DELETE方法从fileserver删除文件。
详情可参考图_2所示:
BlobMessage支持3种文件中转方式:
FILE
要求client和broker在同一个机器或者使用同一个共享存储。发送文件的时候,把文件从本地写入到指定路径。接收文件的时候,把文件从此路径读出来。
HTTP
使用http的fileserver,PUT/GET/DELETE方法。ActiveMQ自带了简单的实现。就是前面场景中使用的方式。
FTP
使用一个独立的ftpserver作为文件中转方式。发送文件的时候,把文件发送到ftp服务器。接收文件的时候,从ftp把文件读取下来。
详见:http://activemq.apache.org/blob-messages.html
优势:消息处理与文件处理传输分开,极大的提高了文件传输的效率。而且可以使用类似jms协议的方式来处理文件发送。
劣势:FILE方式不太实用。HTTP和FTP方式都需要额外的fileserver。
自定义文件传输方式
ActiveMQ实现BlobMessage的三种文件中转方式时,使用了Façade和Strategy模式。 ActiveMQBlobMessage需要在发送消息时使用blobUploader上传文件、接收消息时使用blobDownloader下载文件。每种中转方式的这两个操作分别使用BlobUploadStrategy和BlobDownloadStrategy封装。
所以,我们也可以根据ActiveMQBlobMessage文件传送的原理,实现自己的定制方式:
1、 给ActiveMQBlobMessage添加自己的blobDownloader和blobUploader来实现文件的处理。
2、 扩展这个文件中转机制,实现BlobUploadStrategy和BlobDownloadStrategy。
一个更高效且不需要额外fileserver的实现思路是:broker上再打开一个tcp的监听端口,用来接收和转发文件,当发送和接收端都在时,broker仅仅作为一个传输代理。接收端不在时,broker把数据存为本地临时文件,处理完毕后删除掉。之所以使用一个新的端口来传输文件数据而不是已有的transport,是为了避免jms streams这种命令和数据混合的模式。可以参考ftp协议,作为一种高效的文件传输协议,它有一个很大的特点就是命令的处理,和数据传输的处理使用不同的端口和连接。而ActiveMQ使用的openwire协议其实就是一个个的操作命令。文件分片、包装、序列化,到另一头再反向这个过程,无疑是效率很低下的。