如何选择消息协议: AMQP, MQTT, 还是STOMP？

One of the most common questions I’m asked to cover when I discuss software architecture topics is the difference between the various application messaging protocols that exist tod***—issues like how and why the protocols came about, and which one should be used in a particular application.

Their question is valid.

Tod***, application architects need to use a messaging broker to speed and scale their applications, particularly in the cloud. Even once you select your messaging middleware application, application developers need to then select the protocol. Understanding the subtle differences between them can be difficult.

Tod***, we will consider three of the most common and popular TCP/IP-based messaging protocols, and provide a quick summary on the advantages of each: AMQP , MQTT and STOMP . Before we go on, I should also point out that all three of these protocols are supported in Ra***itMQ version 3.0 —something we will use as an example and come back to later.

So, in alphabetical order…

AMQP , which stands for Advanced Message Queuing Protocol, was designed as an open replacement for existing proprietary messaging middleware. Two of the most important reasons to use AMQP are reliability and interoperability. As the name implies, it provides a wide range of features related to messaging, including reliable queuing, topic-based publish-and-subscribe messaging, flexible routing, transactions, and security. AMQP exchanges route messages directly—in fanout form, by topic, and also based on headers.

There’s a lot of fine-grained control possible with such a rich feature set. You can restrict access to queues, manage their depth, and more. Features like message properties, annotations and headers make it a good fit for a wide range of enterprise applications. This protocol was designed for reliability at the many large companies who depend on messaging to integrate applications and move data around their organisation. In the case of Ra***itMQ, there are many different language implementations and great samples available, making it a good choice for building large scale, reliable, resilient, or clustered messaging infrastructures.

AMQP is a binary wire protocol which was designed for interoperability between different vendors. Where other protocols have failed, AMQP adoption has been strong. Companies like JP Morgan use it to process 1 billion messages a d***. NASA uses it for Nebula Cloud Computing. Google uses it for complex event processing. Here are a couple of additional AMQP examples and links:

It is used in one of the world’s largest biometric databasesIndia’s Aadhar project—home to 1.2 billion identities.

It is used in the Ocean Observatories Initiative —an architecture that collects 8 terabytes of data per d***.

More examples and links are available at amqp.org .

MQTT (Message Queue Telemetry Transport) was originally developed out of IBM’s pervasive computing team and their work with partners in the industrial sector. Over the past couple of years the protocol has been moved into the open source community, seen significant growth in popularity as mobile applications have taken off, and it is in the process of moving into the hands of a standards body.

The design principles and aims of MQTT are much more simple and focused than those of AMQP—it provides publish-and-subscribe messaging (no queues, in spite of the name) and was specifically designed for resource-constrained devices and low bandwidth, high latency networks such as dial up lines and satellite links, for example. Basically, it can be used effectively in embedded systems.

One of the advantages MQTT has over more full-featured “enterprise messaging” brokers is that its intentionally low footprint makes it ideal for tod***’s mobile and developing “ Internet of Things ” style applications. In fact, companies like Facebook are using it as part of their mobile applications bec***se it has such a low power draw and is light on network bandwidth.

Some of the MQTT-based brokers support many thousands of concurrent device connections. It offers three qualities of service: 1) fire-and-forget / unreliable,2) “at least once” to ensure it is sent a minimum of one time (but might be sent more than one time), and 3) “exactly once”.

MQTT’s strengths are simplicity (just five API methods), a compact binary packet p***load (no message properties, compressed headers, much less verbose than something text-based like HTTP), and it makes a good fit for simple push messaging scenarios such as temperature updates, stock price tickers, oil pressure feeds or mobile notifications. It is also very useful for connecting machines together, such as connecting an Arduino device to a web service with MQTT .

Learn more at mqtt.org .

STOMP (Simple/Streaming Text Oriented Messaging Protocol) is the only one of these three protocols to be text-based, making it more ***ogous to HTTP in terms of how it looks under the covers. Like AMQP, STOMP provides a message (or frame) header with properties, and a frame body. The design principles here were to create something simple, and widely-interoperable. For example, it’s possible to connect to a STOMP broker using something as simple as a telnet client.

STOMP does not, however, deal in queues and topics—it uses a SEND semantic with a “destination” string. The broker must map onto something that it understands internally such as a topic, queue, or exchange. Consumers then SUBSCRIBE to those destinations. Since those destinations are not mandated in the specification, different brokers m*** support different flavours of destination. So, it’s not alw***s straightforward to port code between brokers.

However, STOMP is simple and lightweight (although somewhat verbose on the wire), with a wide range of language bindings . It also provides some transactional semantics. One of the most interesting examples is with Ra***itMQ Web Stomp which allows you to expose messaging in a browser through websockets . This opens up some interesting possibilities—like updating a browser, mobile app, or machine in real-time with all types of information.

Learn more at stomp.github.com .

Ra***itMQ: The Polyglot Broker

Hopefully, this can help many begin to navigate the protocol soup out there for each of your use cases. Since it is common for companies to have many applications with different needs, it is certainly possible you m*** need all three brokers across different applications. That’s where a solid multiprotocol, polyglot broker like Ra***itMQ comes in —since it can send STOMP, MQTT, or AMQP in and get one of the other ones out. You don’t need to be locked-in by one of these protocols—all three are supported by the Ra***itMQ broker, making it an ideal choice for interoperability between applications. The plugin architecture also enables Ra***itMQ to evolve to support additional or updated versions of these protocols in the future.

For more information on this protocols and Ra***itMQ, check out the book that VMware’s own Alvaro Videla wrote on this topic: Ra***itMQ in Action .

about the Author: Andy Piper is Developer Advocate for Cloud Foundry, the Open Source Platform-as-a-Service. He is probably best known online as a “social bridgebuilder” spanning a number of areas of technology and interest. He was previously with IBM Software Group for more than 10 years, as a consultant, strategist, and WebSphere Messaging Community Lead.

AMQP协议和ra***itMQ

AMQP，即 高级消息队列协议 (Advanced Message Queuing Protocol)，是一个消息中间件应用层协议，用于组件之间的解耦，来提供 统一消息服务。主要功能是 排序消息，路由消息（包括点对点和订阅-发布），保证消息的可靠性和安全性。

遵循AMPQ协议的客户端，都能通过 消息中间件 相互通信。这样 客户端 就可以采用不同的开发语言实现，彼此无强依赖关系，降低客户端复杂性，提高开发效率也利于后期维护。

AMQP 的模型架构如下：

ra***itMQ是AMQP协议的一个开源实现。架构模型同样可以用以下的图来表示：

如上图，simple模式，单个publisher，单个queue，单个consumer

如上图，work模式

多个consumer共用一个queue的message

此种模式下，ra***itMQ会自动做负载均衡，将消息轮询发送给各个消费者，即一个消息只能被一个消费者获取

如上图，publish / subscribe 发布订阅模式（广播模式）

相对前2种模式，多了一个 exchange (type为fanout) ，message先发送到exchange，exchange再分别发送到对应的所有queue。而consumer订阅自己的queue，在自己订阅的queue上消费message。

示例应用场景，如下图示：

比如 网上购物，下单支付成功后，通知用户的方式有许多种，app推送，短信，email 等等。

message到来后被exchange发送到3个queue（app推送q，短信q，email_q）

之后 app推送服务，短信通知服务，email通知服务 从各自订阅的queue获取消息，通知用户支付成功

如上图示，exchange类型设定为direct

此时 message中的rountingKey 和 exchange中的bindingKey匹配，两者相等则发送对应的queue中，如果匹配不到bindingKey，则丢弃该message。

示例应用场景，如下图示：

比如服务产生的日志，日志有许多类型，error，info，debuf等类型的日志，而我们的需求只想要将 error 类型的日志写入磁盘，就可以用routing模式，将error日志路由到error queue，再由相应的 写入磁盘服务获取message，写入磁盘

如上图示，exchange类型为topic，相对于第4种模式，相同点是都根据 rountingKey 匹配，不同点是 topic 模式支持模糊匹配。

php的amqp应该怎样使用

高级消息队列协议（AMQP）是一个异步消息传递所使用的应用层协议规范。作为线路层协议，而不是API（例如JMS），AMQP 客户端能够无视消息的来源任意发送和接受信息。现在，已经有相当一部分不同平台的服务器和客户端可以投入使用。

1、相关概念说明

Broker：简单来说就是消息队列服务器实体。

Exchange：消息交换机，它指定消息按什么规则，路由到哪个队列。

Queue：消息队列载体，每个消息都会被投入到一个或多个队列。

Binding：绑定，它的作用就是把exchange和queue按照路由规则绑定起来。

Routing Key：路由关键字，exchange根据这个关键字进行消息投递。

vhost：虚拟主机，一个broker里可以开设多个vhost，用作不同用户的权限分离。

producer：消息生产者，就是投递消息的程序。

consumer：消息消费者，就是接受消息的程序。

channel：消息通道，在客户端的每个连接里，可建立多个channel，每个channel代表一个会话任务。

2、使用流程

即 Client - AMQP server - Client左边的Client向右边的Client发送消息，流程：1， 获取Conection2， 获取Channel3， 定义Exchange，Queue4， 使用一个RoutingKey将Queue Binding到一个Exchange上5， 通过指定一个Exchange和一个RoutingKey来将消息发送到对应的Queue上，6， 接收方在接收时也是获取connection，接着获取channel，然后指定一个Queue直接到它关心的Queue上取消息，它对Exchange，RoutingKey及如何binding都不关心，到对应的Queue上去取消息就OK了 。

消息队列概念

消息本质上是一种数据结构（当然，对象也可以看做是一种特殊的消息），它包含消费者与服务双方都能识别的数据，这些数据需要在不同的进程（机器）之间进行传递，并可能会被多个完全不同的客户端消费

队列（Queue） ，是先进先出（FIFO, First-In-First-Out）的线性表，通俗的讲队列就是一群人或者事物按照排好的顺序等待接受服务或者处理

本地队列按照功能可划分为初始化队列，传输队列，目标队列和死信队列。初始化队列用作消息触发功能。传输队列只是暂存待传的消息，条件许可的情况下，通过管道将消息传送到其他的队列管理器。目标队列是消息的目的地，可以长期存放消息。如果消息不能送达目标队列，也不能再路由出去，则被自动放入死信队列保存。

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

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

MQ全称（Message Queue）又名 消息队列 ，是一种 异步通讯 的 中间件 。可以将它理解成邮局，发送者将消息传递到邮局，然后由邮局帮我们发送给具体的消息接收者（消费者），具体发送过程与时间我们无需关心，它也不会干扰我进行其它事情。

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

JMS（JAVA Message Service,java消息服务）是java的消息服务 JMS是一套 API,是j2EE标准的一部分。

JMS是由Sun公司早期提出的消息标准，旨在为java应用提供统一的消息操作，包括create、send、receive等

JMS是Java Enterprise Edition的一部分。从使用角度看，JMS和JDBC担任差不多的角色，用户都是根据相应的接口可以和实现了JMS的服务进行通信，进行相关的操作

结构图

说明

使用 队列（Queue） 作为消息通信载体；满足 生产者与消费者模式 ，一条消息只能被一个消费者使用，未被消费的消息在队列中保留直到被消费或超时。比如：我们生产者发送100条消息的话，两个消费者来消费一般情况下两个消费者会按照消息发送的顺序各自消费一半（也就是你一个我一个的消费。）

结构图

说明

发布订阅模型（Pub/Sub） 使用 主题（Topic） 作为消息通信载体，类似于 广播模式 ；发布者发布一条消息，该消息通过主题传递给所有的订阅者， 在一条消息广播之后才订阅的用户则是收不到该条消息的 。

AMQP(advanced message queuing protocol) 是一个提供统一消息服务的应用层标准协议，基于此协议的客户端与消息中间件可传递消息，并不受客户端/中间件不同产品，可以跨语法开发

AMQP是一种协议，更准确的说是一种binary wire-level protocol（链接协议）,兼容JMS

Spring AMQP杂记之Spring实现简述

上一篇主要介绍了AMQP的一些知识，接下来开始正式步入Spring AMQP。

Message：在AMQP中并没有定义消息的模型，Spring为了方便我们理解与使用，新增了Message接口，在构建消息的时候Spring提供了builde API，MessageBuilder.xx.xx的形式使用起来很方便。

Exchange：这个接口和AMQP中定义的exchange基本相同，就不说了

Queue：同上。

Binding：一般叫他绑定关系，AMQP也有对其的抽象模型，只不过我认为他只不过相当于是附加在队列与交换机上的属性，所以在上篇关于AMQP的介绍中并没有详细说明。呃，其实spring对其的定义就是代表了队列与交换机的绑定关系。。。

spring提供了ConnectionFactory接口，当我们使用的时候会使用它的实现类CachingConnectionFactory，看名字也知道就是基于缓存的连接池，默认的池大小为25。Spring也提供了对于多个connectionFactory的支持接口例如SimpleRoutingConnectionFactory等。

我们使用SpringBoot进行测试，最小化的配置如下

这里先给出一个简单的例子然后再具体讲解。

如图，我们提前声明了一个名为hello的队列，浏览器访问/send时，可以看到控制台打印了相应的时间信息，即被@Ra***itListener注解的方法被调用了。如果我们打开Ra***itMq的webUI，会发现名为hello的队列中消息数量由0变为1再变为0。注意，这里我们并没有声明Exchange，MQ会为我们将队列绑定到默认的Exchange。

接下来就详细的说一下这个例子。对于操作Ra***itMQ，Spring提供了 Ra***itTemplate（对于batch操作，相应的是BatchingRa***itTemplate，在1.6版本以后，spring提供了异步的Template--AsyncRa***itTemplate）。我们使用它来发送与接收消息。当发送完消息的时候如何知道本次操作的成功或者失败呢？默认情况下不能被路由的消息将会被丢弃，这会导致消息丢失，不能保证消息可靠性（消息可靠性请参照上一篇AMQP介绍中的推荐）。发布确认机制是保证消息可靠性的***步，发布确认保证我们知道消息是否成功到达队列中，返回ack则代表成功，nack则代表失败。要使用这个特性，我们需要将Ra***itTemplate的mandatory属性和ConnectionFactory的publisher/confirm/is属性都设为true。这时我们可以在Ra***itTemplate上设置setReturnCallback监听来接收MQ服务器返回的状态信息了。对于消息的确认，我们只需要设置Ra***itTemplate./confirm/iCallback的回调方法即可。

当我们每次发送请求时，都会打印相应的ack，其中correlationData是生产者在发送数据时可以携带的相关信息。这里有个问题需要注意一下,Ra***itTemplate只允许设置一个callback方法，这时你可以将Ra***itTemplate的bean设为单例然后设置回调。

这样的缺点是所有使用这个template的地方都会使用这个回调，那么当我们想要为不同的操作定制callBack该怎么做？如果直接在别的地方继续设置会报"only one ConfirmCallback is supported by each Ra***itTemplate"异常，这时候我们就需要将Ra***itTemplate的作用域设为@Scope，这样每个bean都是一个新的。难道这样就可以了么？我们的service类一般都是单例的，这意味着当service类生成后，注入的Ra***itTemplate就已经不变了，这个就是Single域的bean中注入Scope域bean的问题。一种解决方法是实现ApplicationAware接口注入ApplicationContext，每次使用Ra***itTemplate时调用其getBean方法。一个更好的解决方案是使用spring提供的lookup方法。

spring会帮我们代理lookup注解的方法，每次调用都会返回一个全新的bean。但其实平常使用一般都会将发送方单独抽取出来实现回调接口，不会涉及上面的问题，一般都如下配置，注意将template配置成scope即可。

Ra***itTemplate可以添加消息转换器，作用就类似于mvc中配置的@ResponseBody消息转换器。

具体如何发送与接收消息感觉不用咋说了。。。就send,receive（x,x,x）这个用IDE看一下方法doc就知道咋用了。receive为拉模式，很少使用，关于接收方法我们更常使用的是异步接收，即推模式，一般使用@Ra***itListener 实现

当hello队列中有消息时，方法会自动调用。

像我们平常做web开发，前端想要接受来自后台的消息无非俩个方法，前台请求和后台推送，前台轮询一般就是ajax定时器，推送一般使用WebSocket实现，MQ同样有两种模式：轮询请求队列看是否有消息即拉模式，队列中有消息即对消费者进行通知即推模式。

对于拉模式，Spring提供了receive，receiveAndConvert，和receiveAndReply方法。接收并回复的方法很有用，比如订单系统，下单消息被MQ处理完后再返回消息给其他队列，告诉她这个订单已经完成，可以进行付费操作了。接收并回复调用template.receiveAndReply实现自己的接收回调。对于推模式，项目中基本上使用@Ra***itListener注解完成，该注解结合@SendTo注解完成receiveAndReply功能，若没有sendto，这个方法是不允许有返回值的。对于异常情况，配置@Ra***itListener的errorHandler和returnExceptions即可。关于@Ra***itListener注解的具体使用其实也挺复杂的，推荐直接看文档。使用监听器的过程中消息是默认经过消息转换器的，可以手动为其设置消息转换器。关于Ra***itMQ LIstener的配置可以使用Config方式或者SpringBoot的配置文件方式。

上面只是官方文档的一部分，其实除了Listener大部分Config方式的配置都可以用配置文件方式替代。

声明队列与交换机：分为xml方式和Java Config方式（懒得写了，这个基本官网就是复制粘贴）

配置Broker：Spring对其的抽象为Ra***itAdmin，也是官网。。

延时队列实现：设置交换机延时属性为true，通过convertAndSend中的MessagePostProcessor实现发送延时消息，这个方法需要安装延时交换机这样的一个插件（也可以通过死信队列实现）

好了。今天就先写这么多，因为实在是写的太乱了，以后有时间整理一下。。。

AMQP消息属性详解

《深入Ra***itMQ》读书笔记

本文中对于“契约”的定义：一种确定消息格式和内容的规范。通常用来描述API、对象和系统的预定义规范。契约规范中通常包含有关发送和接收消息的精确信息，例如数据类型、格式以及各种需要遵守的条件。

关于amqp和按摩缺盆十大好处的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。