消息队列协议

最新推荐文章于 2023-02-27 14:56:36 发布

挖坑埋你

最新推荐文章于 2023-02-27 14:56:36 发布

阅读量957

点赞数

分类专栏：消息队列文章标签：消息队列消息队列协议 AMQP

本文链接：https://blog.csdn.net/liupeifeng3514/article/details/111333052

版权

消息队列专栏收录该内容

8 篇文章 2 订阅

订阅专栏

XMPP协议

协议介绍

XMPP的前身是Jabber，一个开源形式组织制定的网络即时通信协议。

XMPP基于XML，用于IM系统的开发。国内比较流行的XMPP实现叫做Openfire，它使用MINA作为下层的网络IO框架；国外用的比较多的XMPP实现叫做Tigase。

当然如果读者所在公司需要开发IM系统，除了使用现成的XMPP服务器以外，还需要实现了XMPP协议的客户端或者开发包（以便进行扩展开发）。您可以在XMPP官网查看到XMPP官方推荐的开发包，各种语言的支持基本上都有。

协议通讯过程示例

为了对XMPP协议有一个感性认识，这里给出一个XMPP协议处理“IM用户登录”操作的过程。

这里写图片描述
通过上图可以看到XMPP协议中的xml片段。这里出现了几个XMPP协议中的关键信息，例如：

stream标记：通讯流标记，是指XMPP的客户端或者服务器端向对方发起的通讯请求（或者响应）。通讯流并不携带正真的内容信息，只是表明客户端和服务器端发生了一次交互。stream的属性包括：to、from、id、xml:lang、version等。
iq标记：iq标记是Info/Query的简称（你可以理解成查询信息请求），一般是一组的形式出现，由客户端发起查询请求，由服务器端返回查询结果。由于查询请求的类型不一样，iq标记中可以嵌入的子标记就有很多。例如，可以嵌入bind标记，表明某个用户和jid的绑定关系；可以嵌入多个item标记，表明查询得到的这个用户的好友信息（如下）。

<iq to='somenode@example.com/someresource' type='result' id='roster'>  
    <query xmlns='jabber:iq:roster'>  
        <item jid='friend1@example.com' name='someone1'/>  
        <item jid='friend2@example.com' name='someone2'/>  
    </query>  
</iq>

jid标记：jid（JabberID）是XMPP协议中标示，它用来标示XMPP网络中的各个XMPP实体（实体可以是某一个用户、某一个服务器、某一个聊天室）。
还有未出现的message、presence标记：message是实体内容标记，记录了聊天的真实内容；presence标记表示了XMPP用户的服务状态（离线，在线、忙碌等）。示例如下：

<message to="somenode@example.com/someresource" type="chat"> 
    <body>helloword。。。</body> 
</message>

Stomp协议

协议介绍

Stomp协议，英文全名Streaming Text Orientated Message Protocol，中文名称为 ‘流文本定向消息协议’。是一种以纯文本为载体的协议。

一个标准的Stomp协议包括以下部分：命令、头信息、文本内容。如下图所示：
这里写图片描述
以下为一段简单的协议信息示例：

CONNECT
accept-version:1.2
someparam1:value1
someparam2:value2

this is conntecon ^@

上面的示例中，我们使用了Stomp协议的CONNECT命令，它的意思为连接到Stomp代理端，并且携带了要求代理端的版本信息和两个自定义的K-V信息（请注意’^@’符号，STOMP协议中用它来表示NULL）。

Stomp协议中有两个重要的角色：STOMP客户端与STOMP消息代理（Broker）。如下图所示：
这里写图片描述
看了上面的示意图后有的读者可能会问：为什么称为Stomp消息代理，而不称为Stomp消息服务？因为Stomp Broker只是负责接受和存储客户端发来的消息、只是按照客户端要求的路径转发消息，只是管理客户端连接和订阅：它并不负责根据消息内容做任何业务处理。所以将它称为消息代理端更贴切。

基本命令/返回信息

和介绍XMPP协议的方式类似，为了对Stomp协议有进一步的认识，本小节介绍Stomp协议的基本命令和代理端返回的信息种类，并且列举一些实例进行使用讲解。

在Stomp协议中，主要有以下命令/返回信息。这些命令/返回信息构成了Stomp协议的主体，并能够支持Stomp客户端和Stomp代理端完成连接、发送、订阅、事务、响应的整个操作过程。这些命令/返回是：

CONNECT：客户端通过使用CONNECT命令，连接到Stomp代理端；
CONNECTED：当Stomp代理端收到客户端发送来的Connect命令并且处理成功后，将向这个客户端返回CONNECTED 状态信息，如果这个过程中出现任何问题，还可能返回ERROR信息；
SEND：客户端使用SEND命令，向某个指定位置（代理端上的一个虚拟路径）发送内容。这样在这个路径上订阅了消息事件的其它客户端，将能够收到这个消息；
SUBSCRIBE：客户端使用SUBSCRIBE订阅命令，向Stomp服务代理订阅某一个虚拟路径上的监听。这样当其它客户端使用SEND命令发送内容到这个路径上时，这个客户端就可以收到这个消息。在使用SUBSCRIBE时，有一个重要的ACK属性。这个ACK属性说明了Stomp服务代理端发送给这个客户端的消息是否需要收到一个ACK命令，才认为这个消息处理成功了。如下所示：

SUBSCRIBE
id:XXXXXXXXX
destination:/test
ack:client

^@

以上SUBSCRIBE命令信息说明，客户端订阅的虚拟位置是test。且命令信息中ack属性为client，说明当客户端收到消息时，必须向代理端发送ack命令，代理端才认为这个消息处理成功了（ack的值只有三种：auto（默认）、client和client-individual）。

UNSUBSCRIBE：客户端使用这个命令，取消对某个路径上消息事件的监听；
MESSAGE：当客户端在某个订阅的位置收到消息时，这个消息将通过MESSAGE关键字进行描述。类似以下信息就是从代理端拿到的消息描述：

MESSAGE
redelivered:true
message-id:ID:localhost-34450-1457321490460-4:24:-1:1:1
destination:/test
timestamp:1457331607873
expires:0
priority:4

2345431457331607861

BEGIN：Stomp协议支持事务模式，在这种模式下，使用Send命令从某个客户端发出的消息，在没有使用COMMIT正式提交前，这些消息是不会真正发送给Stomp代理端的。BEGIN命令用于开启事务。注意，一个事务中可以有一条消息，也可以有多条消息；
COMMIT：当完成事务中的信息定义后，使用该命令提交事务。只有使用COMMIT命令后，在某一个事务中的一条或者多条消息才会进入Stomp代理端的队列（订阅了事件的其它客户端才能收到这些消息）；
ABORT：很明显，这个命令用于取消/终止当前还没有执行COMMIT命令的事务；
ACK：当客户端使用SUBSCRIBE命令进行订阅时，如果在SUBSCRIBE命令中制定ack属性为client，那么这个客户端在收到某条消息后，必须向Stomp代理端发送ACK命令，这样代理端才会认为消息处理成功了；如果Stomp客户端在断开连接之前都没有发送ACK命令，那么Stomp代理端将在这个客户端断开连接后，将这条消息发送给其它客户端。

ACK
id:MESSAGE ID

^@

请注意head部分的id属性，传递的id属性是之前收到的MESSAGE信息的id标示。

NACK：同样是以上的SUBSCRIBE命令的状态下，如果这时Stomp客户端向Stomp代理端发送NACK信息，证明这条消息在这个客户端处理失败。Stomp代理端将会把这条消息发送给另一个客户端（无论当前的客户端是否断开连接）;
DISCONNECT：这个命令将断开Stomp客户端与Stomp代理端的连接。

AMQP协议

AMQP协议的全称是：Advanced Message Queuing Protocol（高级消息队列协议）。

协议介绍

AMQP协议的原理用下图进行一个全面呈现，然后在详细讲解图中的每一个要点：

这里写图片描述
从上图我们可以看到AMQP协议的各个组成部分：

AMQP协议中的元素包括：Message（消息体）、Producer（消息生产者）、Consumer（消息消费者）、Virtual Host（虚拟节点）、Exchange（交换机）、Queue（队列）等；
由Producer（消息生产者）和Consumer（消息消费者）构成了AMQP的客户端，他们是发送消息和接收消息的主体。AMQP服务端称为Broker，一个Broker中一定包含完整的Virtual Host（虚拟主机）、 Exchange（交换机）、Queue（队列）定义；
一个Broker可以创建多个Virtual Host（虚拟主机），我们将讨论的Exchange和Queue都是虚拟机中的工作元素（还有User元素）。注意，如果AMQP是由多个Broker构成的集群提供服务，那么一个Virtual Host也可以由多个Broker共同构成；
Connection是由Producer（消息生产者）和Consumer（消息消费者）创建的连接，连接到Broker物理节点上。但是有了Connection后客户端还不能和服务器通信，在Connection之上客户端会创建Channel，连接到Virtual Host或者Queue上，这样客户端才能向Exchange发送消息或者从Queue接受消息。一个Connection上允许存在多个Channel，只有Channel中能够发送/接受消息；
Exchange元素是AMQP协议中的交换机，Exchange可以绑定多个Queue也可以同时绑定其他Exchange。消息通过Exchange时，会按照Exchange中设置的Routing（路由）规则，将消息发送到符合的Queue或者Exchange中。

那么AMQP消息在这个结构中是如何通过Producer发出，又经过Broker最后到达Consumer的呢？请看下图：

这里写图片描述

在Producer（消息生产者）客户端建立了Channel后，就建立了到Broker上Virtual Host的连接。接下来Producer就可以向这个Virtual Host中的Exchange发送消息了；
Exchange（交换机）能够处理消息的前提是：它至少已经和某个Queue或者另外的Exchange形成了绑定关系，并设置好了到这些Queue和Excahnge的Routing（路由规则）。Excahnge中的Routing有三种模式，我们随后会讲到。在Exchange收到消息后，会根据设置的Routing（路由规则），将消息发送到符合要求的Queue或者Exchange中（路由规则还会和Message中的Routing Key属性配合使用）。
Queue收到消息后，可能会进行如下的处理：如果当前没有Consumer的Channel连接到这个Queue，那么Queue将会把这条消息进行存储直到有Channel被创建（AMQP协议的不同实现产品中，存储方式又不尽相同）；如果已经有Channel连接到这个Queue，那么消息将会按顺序被发送给这个Channel；
Consumer收到消息后，就可以进行消息的处理了。但是整个消息传递的过程还没有完成：视设置情况，Consumer在完成某一条消息的处理后，将需要手动的发送一条ACK消息给对应的Queue（当然您可以设置为自动发送，或者无需发送）。Queue在收到这条ACK信息后，才会认为这条消息处理成功，并将这条消息从Queue中移除；如果在对应的Channel断开后，Queue都没有这条消息的ACK信息，这条消息将会重新被发送给另外的Channel。当然，您还可以发送NACK信息，这样这条消息将会立即归队，并发送给另外的Channel。

Message（消息体）

作为一种网络通讯协议，AMQP工作在七层/五层网络模型的应用层，是一个典型的应用层协议。格式如下：
这里写图片描述
其中非PAYLOAD部分，在网络协议的应用层说明Channel的工作状态（当然还有说明整个AMQP消息的长度区域：SIZE），我们真正需要的内容存在PAYLOAD区域。PAYLOAD区域（译文称为‘交付区’）的格式如下：

在PAYLAOD区域一共包含7个数据区域：header、delivery-annotations、message-annotations、properties、application-properties、application-data、footer。这些元素的作用如下：

header：header记录了消息的交互状态。例如，消息的优先级、TTL值等信息；
delivery-annotations：在header部分只能传递规范的、标准的、经过ISO/IEC组织定义的属性。那么如果需要在header部分传递一些非标准信息怎么办呢？这就是delivery-annotations数据区域存在的意义：用来记录那些“非标”的header信息；
message-annotations：这个数据区域，用于存储一些自定义的辅助属性。和delivery-annotations区域的非标准信息不同，这里的自定义属性主要用于消息的转换。例如，AMQP-JMS信息转换过程中将依据这个数据区域的“x-opt-jms-type”、“x-opt-to-type”、“x-opt-reply-type”和“name”属性进行JMS规范中对应的“JMSType”、“Type of the JMSDestination”、“Type of the JMSReplyTo”和“JMS_AMQP_MA_name”属性的转换；
properties：从整个AMQP消息的properties属性开始，到AMQP消息的application-data部分结束，才是AMQP消息的正文内容。properties属性记录了AMQP消息正文的那些‘不可变’属性。在properties部分只能传递规范的、标准的、经过ISO/IEC组织定义的属性。例如：消息id、分组id、发送者id、内容编码等。以下是AMQP协议文档中对properties部分属性的描述（只能包含这些信息）：

<type name="properties" class="composite" source="list" provides="section">
    <descriptor name="amqp:properties:list" code="0x00000000:0x00000073"/>
    <field name="message-id" type="*" requires="message-id"/>
    <field name="user-id" type="binary"/>
    <field name="to" type="*" requires="address"/>
    <field name="subject" type="string"/>
    <field name="reply-to" type="*" requires="address"/>
    <field name="correlation-id" type="*" requires="message-id"/>
    <field name="content-type" type="symbol"/>
    <field name="content-encoding" type="symbol"/>
    <field name="absolute-expiry-time" type="timestamp"/>
    <field name="creation-time" type="timestamp"/>
    <field name="group-id" type="string"/>
    <field name="group-sequence" type="sequence-no"/>
    <field name="reply-to-group-id" type="string"/>
</type>

application-properties：在这部分数据中主要记录和应用有关的数据，AMQP的实现产品（例如RabbitMQ）需要用这部分数据决定其处理逻辑。例如：送入哪一个Exchange、消息的Routing值是什么、是否进行持久化等；
application-data：使用二进制格式描述的AMQP消息的用户部分内容。既是我们发送出去的真实内容；
footer：一般在这个数据区域存储辅助内容，例如消息的哈希值，HMAC，签名或者加密细节。

以上才是一个AMQP消息的完整结构。当然由于篇幅限制，在某一个数据区域的‘标准’属性就没有再细讲了，例如Properties数据区域定义的creation-time属性、Header数据区域定义的durable属性。

Exchange（交换机）路由规则

Exchange交换机在AMQP协议中主要负责按照一定的规则，将收到的消息转发到已经和它事先绑定好的Queue或者另外的Exchange中。Excahnge交换机的这个处理过程称之为Routing（路由）。目前流行的AMQP路由实现一共有三种：分别是Direct Exchange、Fanout Exchange和Topic Exchange。

需要特别注意的是：Exhange需要具备怎样的‘路由’规则，并没有在AMQP标准协议进行强行规定，目前流行的AMQP转发规则都是AMQP实现产品自行开发的（这也是为什么AMQP消息中和路由、过滤规则相关的属性是存放在application-properties区域的原因）。

A、Direct路由

direct模式下Exchange将使用AMQP消息中所携带的Routing-Key和Queue中的Routing Key进行比较。如果两者完全匹配，就会将这条消息发送到这个Queue中。如下图所示：
这里写图片描述
B、Fanout路由

Fanout路由模式不需要Routing Key。当设置为Fanout模式的Exchange收到AMQP消息后，将会将这个AMQP消息复制多份，分别发送到和自己绑定的各个Queue中。如下图所示：

这里写图片描述
C、Topic路由

Topic模式是Routing Key的匹配模式。Exchange将支持使用‘#’和‘ * ’通配符进行Routing Key的匹配查找（‘#’表示0个或若干个关键词，‘ * ’表示一个关键词，注意是关键词不是字母）。如下图所示：

这里写图片描述
为了方便各位读者的理解，这里我们再举几个通配符匹配的示例：

“param.#”，可以匹配“param”、“param.test”、“param.value”、“param.test.child”等等AMQP消息的Routing
Key；但是不能匹配诸如“param1.test”、“param2.test”、“param3.test”。以为param这个关键词和param1这个关键词不相同。
“param.*.*”，可以匹配“param.test.test”、“param.test.value”、“param.test.child”等等AMQP消息的Routing
Key；但是不能匹配诸如“param”、“param.test”、“parm.child”等等Routing Key。
“param.*.value”，可以匹配“param.value.value”、“param.test.value”等Routing Key；但是不能匹配诸如“param.value”、“param.value.child”等Routing Key。

注意，以上介绍的Direct 路由模式和Topic 路由模式中，如果Exchange交换机没有找到任何匹配Routing Key的Queue，那么这条AMQP消息会被丢弃。（只有Queue有保存消息的功能，但是Exchange并不负责保存消息）

挖坑埋你

关注

0
点赞
踩
1

收藏

觉得还不错? 一键收藏
0
评论
消息队列协议

XMPP协议协议介绍XMPP的前身是Jabber，一个开源形式组织制定的网络即时通信协议。XMPP基于XML，用于IM系统的开发。国内比较流行的XMPP实现叫做Openfire，它使用MINA作为下层的网络IO框架；国外用的比较多的XMPP实现叫做Tigase。当然如果读者所在公司需要开发IM系统，除了使用现成的XMPP服务器以外，还需要实现了XMPP协议的客户端或者开发包（以便进行扩展开发）。您可以在XMPP官网查看到XMPP官方推荐的开发包，各种语言的支持基本上都有。协议通讯过程示例为了对
复制链接

扫一扫