MQ消息队列

AMQP协议介绍

AMQP，即Advanced Message Queuing Protocol，高级消息队列协议，是应用层协议的一个开放标准，为面向消息的中间件设计。

AMQP的主要特征是面向消息、队列、路由（包括点对点和发布/订阅）、可靠性、安全。

AMQP在消息提供者和客户端的行为进行了强制规定，使得不同卖商之间真正实现了互操作能力。

JMS是早期消息中间件进行标准化的一个尝试，它仅仅是在API级进行了规范，离创建互操作能力还差很远。

与JMS不同，AMQP是一个Wire级的协议，它描述了在网络上传输的数据的格式，以字节为流。因此任何遵守此数据格式的工具，其创建和解释消息，都能与其他兼容工具进行互操作。

AMQP规范的版本：
0-8 是2006年6月发布
0-9 于2006年12月发布
0-9-1 于2008年11月发布
0-10 于2009年下半年发布
1.0 draft （文档还是草案）

AMQP的实现有：

1）OpenAMQ
AMQP的开源实现，用C语言编写，运行于Linux、AIX、Solaris、Windows、OpenVMS。

2）Apache Qpid
Apache的开源项目，支持C++、Ruby、Java、JMS、Python和.NET。

3）Redhat Enterprise MRG
实现了AMQP的最新版本0-10，提供了丰富的特征集，比如完全管理、联合、Active-Active集群，有Web控制台，还有许多企业级特征，客户端支持C++、Ruby、Java、JMS、Python和.NET。

4）RabbitMQ
一个独立的开源实现，服务器端用Erlang语言编写，支持多种客户端，如：Python、Ruby、.NET、Java、JMS、C、PHP、ActionScript、XMPP、STOMP等，支持AJAX。RabbitMQ发布在Ubuntu、FreeBSD平台。

5）AMQP Infrastructure
Linux下，包括Broker、管理工具、Agent和客户端。

6）ØMQ
一个高性能的消息平台，在分布式消息网络可作为兼容AMQP的Broker节点，绑定了多种语言，包括Python、C、C++、Lisp、Ruby等。

7）Zyre
是一个Broker，实现了RestMS协议和AMQP协议，提供了RESTful HTTP访问网络AMQP的能力。

JMS协议介绍

JMS（Java Messaging Service）是Java平台上有关面向消息中间件的技术规范，它便于消息系统中的Java应用程序进行消息交换,并且通过提供标准的产生、发送、接收消息的接口简化企业应用的开发。

JMS本身只定义了一系列的接口规范，是一种与厂商无关的 API，用来访问消息收发系统。它类似于 JDBC(Java Database Connectivity)：这里，JDBC 是可以用来访问许多不同关系数据库的 API，而 JMS 则提供同样与厂商无关的访问方法，以访问消息收发服务。许多厂商目前都支持 JMS，包括 IBM 的 MQSeries、BEA的 Weblogic JMS service和 Progress 的 SonicMQ，这只是几个例子。 JMS 使您能够通过消息收发服务（有时称为消息中介程序或路由器）从一个 JMS 客户机向另一个 JML 客户机发送消息。消息是 JMS 中的一种类型对象，由两部分组成：报头和消息主体。报头由路由信息以及有关该消息的元数据组成。消息主体则携带着应用程序的数据或有效负载。根据有效负载 的类型来划分，可以将消息分为几种类型，它们分别携带：简单文本 (TextMessage)、可序列化的对象 (ObjectMessage)、属性集合 (MapMessage)、字节流 (BytesMessage)、原始值流 (StreamMessage)，还有无有效负载的消息 (Message)。

STOMP协议介绍

STOMP，Streaming Text Orientated Message Protocol，是流文本定向消息协议，是一种为MOM(Message Oriented Middleware，面向消息的中间件)设计的简单文本协议。

它提供了一个可互操作的连接格式，允许STOMP客户端与任意STOMP消息代理(Broker)进行交互，类似于OpenWire(一种二进制协议)。

由于其设计简单，很容易开发客户端，因此在多种语言和多种平台上得到广泛应用。其中最流行的STOMP消息代理是Apache ActiveMQ。

STOMP协议工作于TCP协议之上，使用了下列命令：

* SEND 发送
* SUBSCRIBE 订阅
* UNSUBSCRIBE 退订
* BEGIN 开始
* COMMIT 提交
* ABORT 取消
* ACK 确认
* DISCONNECT 断开

消息中间件概况

消息队列技术是分布式应用间交换信息的一种技术。消息队列可驻留在内存或磁盘上,队列存储消息直到它们被应用程序读走。通过消息队列，应用程序可独立地执行--它们不需要知道彼此的位置、或在继续执行前不需要等待接收程序接收此消息。

在分布式计算环境中，为了集成分布式应用，开发者需要对异构网络环境下的分布式应用提供有效的通信手段。为了管理需要共享的信息，对应用提供公共的信息交换机制是重要的。

设计分布式应用的方法主要有：远程过程调用(PRC)-分布式计算环境(DCE)的基础标准成分之一；对象事务监控(OTM)-基于CORBA的面向对象工业标准与事务处理(TP)监控技术的组合；消息队列(MessageQueue)-构造分布式应用的松耦合方法。

(a) 分布计算环境/远程过程调用 (DCE/RPC)

RPC是DCE的成分，是一个由开放软件基金会(OSF)发布的应用集成的软件标准。RPC模仿一个程序用函数引用来引用另一程序的传统程序设计方法，此引用是过程调用的形式，一旦被调用，程序的控制则转向被调用程序。

在RPC 实现时，被调用过程可在本地或远地的另一系统中驻留并在执行。当被调用程序完成处理输入数据，结果放在过程调用的返回变量中返回到调用程序。RPC完成后程序控制则立即返回到调用程序。因此RPC模仿子程序的调用/返回结构，它仅提供了Client(调用程序)和Server(被调用过程)间的同步数据交换。

(b) 对象事务监控 (OTM)

基于CORBA的面向对象工业标准与事务处理(TP)监控技术的组合，在CORBA规范中定义了：使用面向对象技术和方法的体系结构；公共的 Client/Server程序设计接口；多平台间传输和翻译数据的指导方针；开发分布式应用接口的语言(IDL)等，并为构造分布的 Client/Server应用提供了广泛及一致的模式。

(c) 消息队列 (Message Queue)

消息队列为构造以同步或异步方式实现的分布式应用提供了松耦合方法。消息队列的API调用被嵌入到新的或现存的应用中，通过消息发送到内存或基于磁盘的队列或从它读出而提供信息交换。消息队列可用在应用中以执行多种功能，比如要求服务、交换信息或异步处理等。

中间件是一种独立的系统软件或服务程序，分布式应用系统借助这种软件在不同的技术之间共享资源，管理计算资源和网络通讯。它在计算机系统中是一个关键软件，它能实现应用的互连和互操作性，能保证系统的安全、可靠、高效的运行。中间件位于用户应用和操作系统及网络软件之间，它为应用提供了公用的通信手段，并且独立于网络和操作系统。中间件为开发者提供了公用于所有环境的应用程序接口，当应用程序中嵌入其函数调用，它便可利用其运行的特定操作系统和网络环境的功能，为应用执行通信功能。

如果没有消息中间件完成信息交换，应用开发者为了传输数据，必须要学会如何用网络和操作系统软件的功能，编写相应的应用程序来发送和接收信息，且交换信息没有标准方法，每个应用必须进行特定的编程从而和多平台、不同环境下的一个或多个应用通信。例如，为了实现网络上不同主机系统间的通信，将要求具备在网络上如何交换信息的知识（比如用TCP/IP的socket程序设计）；为了实现同一主机内不同进程之间的通讯，将要求具备操作系统的消息队列或命名管道(Pipes)等知识。

目前中间件的种类很多，如交易管理中间件、面向Java应用的Web应用服务器中间件等，而消息传输中间件(MOM)是其中的一种。它简化了应用之间数据的传输，屏蔽底层异构操作系统和网络平台，提供一致的通讯标准和应用开发，确保分布式计算网络环境下可靠的、跨平台的信息传输和数据交换。它基于消息队列的存储-转发机制，并提供特有的异步传输机制，能够基于消息传输和异步事务处理实现应用整合与数据交换。

发布-订阅消息模式

一、订阅杂志

我们很多人都订过杂志，其过程很简单。只要告诉邮局我们所要订的杂志名、投递的地址，付了钱就OK。出版社定期会将出版的杂志交给邮局，邮局会根据订阅的列表，将杂志送达消费者手中。这样我们就可以看到每一期精彩的杂志了。

仔细思考一下订杂志的过程，我们会发现这样几个特点：1、消费者订杂志不需要直接找出版社；2、出版社只需要把杂志交给邮局；3、邮局将杂志送达消费者。邮局在整个过程中扮演了非常重要的中转作用，在出版社和消费者相互不需要知道对方的情况下，邮局完成了杂志的投递。
二、发布-订阅消息模式

刚刚讲了订阅杂志，下面我们会讲传统调用模式演化到发布-订阅消息模式。
有些网站在注册用户成功后发一封激活邮件，用户收到邮件后点击激活链接后才能使用该网站。一般的做法是在注册用户业务逻辑中调用发送邮件的逻辑。这 样用户业务就依赖于邮件业务。如果以后改为短信激活，注册用户业务逻辑就必须修改为调用发送短信的逻辑。如果要注册后给用户加点积分，再加一段逻辑。经过 多次修改，我们发现很简单的注册用户业务已经越来越复杂，越来越难以维护。相信很多开发者都会有类似痛苦的经历。

即使用户业务实现中对其他业务是接口依赖，也避免不了业务变化带来的依赖影响。怎么办？解耦！将注册用户业务逻辑中注册成功后的处理剥离出来。
再回头看看"订阅杂志"，如果没有邮局，出版社就必须自己将杂志送达所有消费者。这种情形就和现在的注册用户业务一样。我们发现问题了，在用户业务和其他业务之间缺少了邮局所扮角色。
我们把邮局抽象成一个管理消息的地方，叫"消息管理器"。注册用户成功后发送一个消息给消息管理器，由消息管理器转发该消息给需要处理的业务。现在，用户业务只依赖于消息管理器了，它再也不会为了注册用户成功后的其他处理而烦恼。

注册用户的改造就是借鉴了"订阅杂志"这样原始的模式。我们再进一步抽象，用户业务就是消息的"生产者"，它将消息发布到消息管理器。邮件业务就是 消息的"消费者"，它将收到的消息进行处理。邮局可以订阅很多种杂志，杂志都是通过某种编号来区分；消息管理器也可以管理多种消息，每种消息都会有一个 "主题"来区分，消费者都是通过主题来订阅的。

发布-订阅消息模式已经呈现在我们面前，利用它可以产生更灵活、更松散耦合的系统。

MQ相关概念

1.消息(Message)

消息是MQ中最小的概念，本质上就是一段数据，它能被一个或者多个应用程序所理解，是应用程序之间传递的信息载体。

2.队列(Queue）

2.1本地队列

本地队列按照功能可划分为初始化队列，传输队列，目标队列和死信队列。

初始化队列用作消息触发功能。

传输队列只是暂存待传的消息，条件许可的情况下，通过管道将消息传送到其他的队列管理器。

目标队列是消息的目的地，可以长期存放消息。

如果消息不能送达目标队列，也不能再路由出去，则被自动放入死信队列保存。

2.2别名队列&远程队列

只是一个队列定义，用来指定远端队列管理器的队列。使用了远程队列，程序就不需要知道目标队列的位置。

2.3模型队列

模型队列定义了一套本地队列的属性结合，一旦打开模型队列，队列管理器会按照这些属性动态地创建出一个本地队列。

3.队列管理器(Queue Manager)

队列管理器是一个负责向应用程序提供消息服务的机构，如果把队列管理器比作数据库，那么队列就是其中一张表。

4.通道(Channel)

通道是两个管理器之间的一种单向点对点的的通信连接，如果需要双向交流，可以建立一对通道。

5.监听器(listner)

MQ产品的特性

可靠性传输

这个特点可以说是消息中间件的立足之本，对于应用来说，只要成功把数据提交给消息中间件，那么关于数据可靠传输的问题就由消息中间件来负责。

不重复传输

不重复传播也就是断点续传的功能，特别适合网络不稳定的环境，节约网络资源。

异步性传输

异步性传输是指，接受信息双方不必同时在线，具有脱机能力和安全性。

消息驱动

接到消息后主动通知消息接收方。

支持事务

应用程序可以把一些数据更新组合成一个工作单元，这些更新通常是逻辑相关的，为了保障数据完整性，所有的更新必须同时成功或者同时失败）。

常用MQ产品比较

	ActiveMQ	Joram	HornetQ	OpenMQ	MuleMQ	SonicMQ	RabbitMQ	ZeroMQ
关注度	高	中	中	中	低	低	高	中
成熟度	成熟	比较成熟	比较成熟	比较成熟	新产品无成功案例	成熟	成熟	不成熟
所属社区/公司	Apache	OW2	Jboss	Sun	Mule	Progress
社区活跃度	高	中	中	低	高	低	高	低
文档	多	多	中	中	少	少	多	中
特点	功能齐全，被大量开源项目使用		在Linux平台上直接调用操作系统的AIO，性能得到很大的提升		性能非常好，与MuleESB无缝整合	性能优越的商业MQ	由于Erlang语言的并发能力，性能很好	低延时，高性能，最高43万条消息每秒
授权方式	开源	开源	开源	开源	商业	商业	开源	开源
开发语言	Java	Java	Java	Java	Java	Java	Erlang	C
支持的协议	OpenWire、STOMP、REST、XMPP、AMQP	JMS	JMS	JMS	JMS	JMS	AMQP	TCP、UDP
客户端支持语言	Java、C、C++、Python、PHP、Perl、.net等	Java	Java	Java	Java	Java、C、C++、.net	Java、C、C++、Python、PHP、Perl等	python、java、php、.net等
持久化	内存、文件、数据库	内存、文件	内存、文件	内存、文件	内存、文件	内存、文件、数据库	内存、文件	在消息发送端保存
事务	支持	支持	支持	支持	支持	支持	不支持	不支持
集群	支持	支持	支持	支持	支持	支持	支持	不支持
负载均衡	支持	支持	支持	支持	支持	支持	支持	不支持
管理界面	一般	一般	无	一般	一般	好	无	无
部署方式	独立、嵌入	独立、嵌入	独立、嵌入	独立、嵌入	独立	独立	独立	独立
评价	成熟稳定，开源首选	依赖容器，不适合跨语言调用	推出的时间不长，尚无使用案例，不适合跨语言调用	依赖容器，不适合跨语言调用	推出的时间不长，无成功案例，目前仅支持Java	成熟稳定	Queue的数量大于50后，高并发下无法持续稳定的提供服务	不支持事务、集群，并且消息不能在服务端持久化

MQ适用场景介绍

MQ消息队列是应运松偶合的概念而产生的，主要以队列和发布订阅为消息传输机制，以异步的方式将消息可靠的传输到消费端的一种基础产品。

它被广泛的应用与跨平台、跨系统的分布式系统之间，为它们提供高效可靠的异步传输机制。

• 消息通道（Message Channel）

使用MQ将彼此协作的客户端和服务端连接起来，使他们可以交换消息。

如客户端与服务端需要安全可靠的交互，可以将一个MQ的队列作为安全通道，是客户端与服务端能够安全高效的进行异步通讯。

• 消息总线（Message Bus）

对于由许多独立开发的服务组成的分布式系统，倘若要将它们组成一个完整的系统，这些服务必须能够可靠地交互，同时，为了系统的健壮性，

每个服务之间又不能产生过分紧密的依赖关系，这样就可以通过消息总线将不同的服务连接起来，允许它们异步的传递数据。

• 消息路由（Message Router）

通过消息路由，可以将发送到MQ指定队列的消息根据规则路由到不同的队列。

此外，JMS规范还支持通过selector条件，对消息进行过滤，可以用多个消费者消费同一个队列的消息，每个消费者只消费自己感兴趣的消息。

• 发布/订阅（Publicsher/Subscriber）

发布/订阅模式用于一对多的通讯，当消息发布者向一个主题（Topic）发送一条消息后，该主题的所有订阅者都会收到这条消息。