1、前言
之前我们通过两篇文章(架构设计:系统间通信(19)——MQ:消息协议(上)、架构设计:系统间通信(20)——MQ:消息协议(下))从理论层面上为大家介绍了消息协议的基本定义,并花了较大篇幅向读者介绍了三种典型的消息协议:XMPP协议、Stomp协议和AMQP协议。本小节开始,我们基于之前的知识点讲解这些协议在具体的“消息队列中间件”中是如何被我们操作的。由于本人在实际工作中经常使用ActiveMQ和RabbitMQ,所以就选取这两个“消息队列中间件”进行讲解。如果读者可以补充其他“消息队列中间件”的使用,那当然是再好不过了。
2、ActiveMQ的安装和使用
ActiveMQ是Apache软件基金会的开源产品,支持AMQP协议、MQTT协议(和XMPP协议作用类似)、Openwire协议和Stomp协议等多种消息协议。并且ActiveMQ完整支持JMS API接口规范(当然Apache也提供多种其他语言的客户端,例如:C、C++、C#、Ruby、Perl)。
2-1、ActiveMQ的安装
在本文发布之时,ActiveMQ最新的版本号是5.13.2(版本号升级很快,不过并不推荐使用最新的版本)。由ActiveMQ的安装是很简单,所以这个过程并不值得我们花很大篇幅进行讨论。具体的过程就是:下载->解压->配置环境变量->运行:
- 下载软件
您可以Apache ActiveMQ的官网下载安装包:https://activemq.apache.org/download-archives.html。这里我们示例在CentOS下的安装过程,所以下载Linux下的压缩包即可(http://www.apache.org/dyn/closer.cgi?path=/activemq/5.13.2/apache-activemq-5.13.2-bin.tar.gz)。
- 解压安装
将下载的安装包放置在root用户的home目录内,解压即可(当然您可以根据自己的需要加压到不同的文件路径下)。如下所示:
- 1
以上解压使用的是root用户,这是为了演示方便。正式环境中还是建议禁用root用户,为activeMQ的运行专门创建一个用户和用户组。
- 配置环境变量(不是必须的)
如果您只是在测试环境使用Apache ActiveMQ,以便熟悉消息中间件本身的特性和使用方式。那么您无需对解压后的软件进行任何配置,所有可运行的命令都在软件安装目录的./bin目录下。为了使用方便,最好配置一下环境变量,如下所示(注意,根据您自己的软件安装位置,环境变量的设置是不一样的,请不要盲目粘贴复制):
- 1
- 2
- 3
- 4
- 5
在ActiveMQ Version 5.9+的版本中,Apache ActiveMQ 针对操作系统进行了更深入的优化,所以您可以看到./bin目录下,有一个针对32位Linux运行命令的./linux-x86-32目录,和针对64位Linux运行命令的./linux-x86-64目录。请按照您自己的情况进行环境变量设置和命令运行。
- 运行程序
现在您可以在任何目录,运行activemq命令了。注意activemq命令一共有6个参数(console | start | stop | restart | status | dump),启动Apache ActiveMQ使用的命令是activemq start:
- 1
如果启动成功,就可以在浏览器上访问服务节点在8161端口的管理页面了(例如http://localhost:8161):
点击‘manage ActiveMQ broker’连接,可以进入管理主界面(默认的用户和密码都是admin)。以上就是Apache ActiveMQ消息中间件最简的安装和运行方式。在后续的文章中,我们会陆续讨论ActiveMQ的集群和高性能优化,那时会介绍对应的ActiveMQ的配置问题。
2-2、ActiveMQ的其他命令参数
如同上文讲到的,activemq命令除了start参数用于启动activemq程序以外,还有另外5个参数可以使用:console | stop | restart | status | dump。他们代表的使用意义是:
-
stop:停止当前ActiveMQ节点的运行。
-
restart:重新启动当前ActiveMQ节点。
-
status:查看当前ActiveMQ节点的运行状态。如果当前ActiveMQ节点没有运行,那么将返回“ActiveMQ Broker is not running”的提示信息。注意,status命令只能告诉开发人员当前节点时停止的还是运行的,除此之外不能从status命令获取更多的信息。例如,ActiveMQ为什么创建Queue失败?当前ActiveMQ使用了多少内存?而要获取这些信息,需要使用以下参数启动ActiveMQ节点。
-
console:使用控制台模式启动ActiveMQ节点;在这种模式下,开发人员可以调试、监控当前ActivieMQ节点的实时情况,并获取实时状态。
-
dump:如果您采用console模式运行ActiveMQ,那么就可以使用dump参数,在console控制台上获取当前ActiveMQ节点的线程状态快照。
2-3、在ActiveMQ中传递Stomp消息
好吧,既然我们已经讨论过如何安装和运行ActiveMQ,也讨论了Stomp协议的组织结构,为什么我们不立即动手试一试操作ActiveMQ承载Stomp协议的消息呢?
下面我们使用ActiveMQ提供的JAVA 客户端(实际上就是ActiveMQ对JMS规范的实现),向ActiveMQ中的Queue(示例代码中将这个Queue命名为’test’)发送一条Stomp协议消息,然后再使用JAVA语言的客户端,从ActiveMQ上接受这条消息:
- 使用ActiveMQ的API发送Stomp协议消息:
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 使用ActiveMQ的API接收Stomp协议消息:
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
以上分别是使用Activie提供的Stomp协议的消息生产端和Stomp协议的消息消费端的代码(如果您不清楚Stomp协议的细节,可以参考我另一篇文章:《架构设计:系统间通信(19)——MQ:消息协议(上)》)。请注意在代码片段中,并没有出现任何一个带有jms名称的包或者类——这是因为ActiveMQ为Stomp协议提供的JAVA API在内部进行了JMS规范的封装。
您可以查看activemq-stomp中关于协议转换部分的源代码:org.apache.activemq.transport.stomp.JmsFrameTranslator和其父级接口:org.apache.activemq.transport.stomp.FrameTranslator来验证这件事情(关于ActiveMQ对JMS规范的实现设计,如果后续有时间再回头进行讲解)。
以下是Stomp协议的消费者端的运行效果(在生产者端已经向ActiveMQ插入了一条消息之后):
- 1
- 2
- 3
注意,由于消息体中插入了一个时间戳,所以您复制粘贴代码后运行效果并不会和我的演示程序完全一致。
2-4、ActiveMQ中的Queue和Topics
如果您细心的话,在ActiveMQ提供的管理页面上已经看到有两个功能页面:Queue和Topic。Queue和Topic是JMS为开发人员提供的两种不同工作机制的消息队列。 在ActiveMQ官方的解释是:
- Topics
In JMS a Topic implements publish and subscribe semantics. When you publish a message it goes to all the subscribers who are interested - so zero to many subscribers will receive a copy of the message. Only subscribers who had an active subscription at the time the broker receives the message will get a copy of the message.
中文的可以译做:JMS-Topic 队列基于“订阅-发布”模式,当操作者发布一条消息后,所有对这条消息感兴趣的订阅者都可以收到它——也就是说这条消息会被拷贝成多份,进行分发。只有当前“活动的”订阅者能够收到消息(换句话说,如果当前JMS-Topic队列中没有订阅者,这条消息将被丢弃)。
- Queue
A JMS Queue implements load balancer semantics. A single message will be received by exactly one consumer. If there are no consumers available at the time the message is sent it will be kept until a consumer is available that can process the message. If a consumer receives a message and does not acknowledge it before closing then the message will be redelivered to another consumer. A queue can have many consumers with messages load balanced across the available consumers.
So Queues implement a reliable load balancer in JMS.
中文的可以译做:JMS-Queue是一种“负载均衡模式”的实现。一个消息能且只能被一个消费者接受。如果当前JMS-Queue中没有任何的消费者,那么这条消息将会被Queue存储起来(实际应用中可以存储在磁盘上,也可以存储在数据库中,看软件的配置),直到有一个消费者连接上。另外,如果消费者在接受到消息后,在他断开与JMS-Queue连接之前,没有发送ack信息(可以是客户端手动发送,也可以是自动发送),那么这条消息将被发送给其他消费者。
以下表格摘自互联网上的资料,基本上把Queue和Topic这两种队列的不同特性说清楚了:
比较项目 | Topic 模式队列 | Queue 模式队列 |
---|---|---|
工作模式 | “订阅-发布”模式,如果当前没有订阅者,消息将会被丢弃。如果有多个订阅者,那么这些订阅者都会收到消息 | “负载均衡”模式,如果当前没有消费者,消息也不会丢弃;如果有多个消费者,那么一条消息也只会发送给其中一个消费者,并且要求消费者ack信息。 |
有无状态 | 无状态 | Queue数据默认会在mq服务器上以文件形式保存,比如Active MQ一般保存在$AMQ_HOME\data\kr-store\data下面。也可以配置成DB存储。 |
传递完整性 | 如果没有订阅者,消息会被丢弃 | 消息不会丢弃 |
处理效率 | 由于消息要按照订阅者的数量进行复制,所以处理性能会随着订阅者的增加而明显降低,并且还要结合不同消息协议自身的性能差异 | 由于一条消息只发送给一个消费者,所以就算消费者再多,性能也不会有明显降低。当然不同消息协议的具体性能也是有差异的 |
2-5、JMS和协议间转换
上文已经说到,JMS这套面向消息通信的 JAVA API 是一个和厂商无关的规范。通过JMS,我们能实现不同消息中间件厂商、不同协议间的转换和交互。这一小节我们就来讨论一下这个问题。如果用一张图来表示JMS在消息中间件中的作用话,那么就可以这么来画:
首先您使用的MQ消息中间件需要实现了JMS规范;那么通过JMS规范,开发人员可以忽略各种消息协议的细节,只要消息在同一队列中,就能够保证各种消息协议间实现互相转换。下面我们首先来看一个使用JMS API在ActiveMQ中操作openwire协议消息的简单示例,然后再给出一个通过JMS,实现Stomp消息协议和Openwire消息协议间的互转示例。
2-5-1、JMS操作
- 以下代码使用向某个Queue(命名为test)中发送一条消息:
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
- 48
- 49
当以上代码运行到“start”的位置时,我们可以通过观察ActiveMQ管理界面中connection列表中的连接信息,发现消息生产者已经建立了一个Openwire协议的连接:
从而确定我们通过JMS API建立了一个openwire协议的通讯连接。接着我们使用以下代码,建立一个基于openwire协议的“消费者”。注意:消息生产者和消息消费者,映射的队列必须一致。(在示例代码中,它们都映射名称为test的JMS-Queue)
- 以下代码使用JMS从某个Queue中接收消息:
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
- 48
- 49
- 50
- 51
- 52
- 53
- 54
- 55
- 56
- 57
当以上“消费者”代码运行到start的位置时,我们通过ActiveMQ提供的管理界面可以看到,基于Openwire协议的连接增加到了两条:
注意,您在运行以上测试代码时,不用和我的运行顺序一致。由于Queue模式的队列是要进行消息状态保存的,所以无论您是先运行“消费者”端,还是先运行“生产者”端,最后“消费者”都会收到一条消息。类似如下的效果:
- 1
2-5-2、协议间转换
下面我们将Openwire协议的消息通过JMS送入Queue队列,并且让基于Stomp协议的消费者接收到这条消息。为了节约篇幅,基于Openwire协议的生产者的代码请参考上一小节2-5-1中“生产者”的代码片段。这里只列出Stomp消息的接受者代码(实际上这段代码在上文中也可以找到):
- Stomp协议的消息消费者(消息接收者):
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
当您同时运行Openwire消息发送者和Stomp消息接收者时,您可以在ActiveMQ的管理界面看到这两种协议的连接信息:
以下是Stomp协议消费者接收到的消息内容(经过转换的openwire协议消息):
- 1
- 2
- 3
接下文