前言

简单理解
就是需要大家都遵守的 套规 。在计算机领域中,只要涉及不同的计算机之间要共同完成一
事情的时候,就肯定会有协议的存在,就像我们说话用某种语言一样,不 同的计算机之间必
须使用相同的语 才能进行通信
在这里插入图片描述
消息协议则是指用于实现消息队列功能时所涉及的协议。按照是否向行业开放消息规范文
档,可以将消息协议分为开放协议和私有协议。常见的开放协议有 AMQP, MQTT STOMP,XMPP 等。有些特殊框架(如 Red Kafka ZeroMQ )根据自身需要未严格遵循 MQ 规范,而
是基于 TCP IP 自行封装了 协议,通过网 Socket 接口进行传输,实现了 MQ 的功能。这
的协议可以简 地理解成对双方通信 个约定,比如传过来 衍流数据,其中第
节表示什么, 字节表示什么,类似这样的约定。本章主要介绍常见的几种开放协议,
并且主要围绕每种协议约定的数据格式来阐述,包括每种协议中的基本概念, 及约定的互相
通信的消息数据格式等。

AMQP协议

amqp的三个部分
  1. 基本概念:基本概念是指 AMQP 内部定义的各组件及组件的功能说明
  2. 功能命令:是指该协议所定义的 系列命令,应用程序可以基于这些命令来实现相应的功能
  3. 传输层协议:是一个网络级协议,它定义了数据的 传输格式,消息队列的客户端可以基于这个协议与消息代理和 AMQP 的相模型进行交互通信,该协议的内容包括数据, 吭处理、信道 用、内容编码、心跳检测、数据表示和错误处理等。
主要概念
  • Message (消息):消息服务器所处理数据的原子单元。消息可以携带内容,从格式上看,消息包括 个内容头、 组属性和 个内容体这里所说的消息可以对应到许多不同应用程序的实体,比如 个应用程序级消息、 个传输文件、 个数据流帧等。消息可以被保存到磁盘上这样即使发生严重的网络故障、服务器崩溃 可确保投递。消息可以有优先级,高优先级的消息会在等待同 个消息队列时在低优先级的消息之前发送,当消息必须被丢弃以确保消息服务器的服务质量时,服务器将会优先丢弃低优先级的消息 。消息服务器不能修改所接收到的井将传递给消费者应用程序的消息容体。消息服务器可以在内容头中添加额外信息,但不能删除或修改现有信息。
  • Publisher (消息生产者)也是 个向交换器发布消息的客户端应用程序 对于java来说就是发送请求的那一段代码
  • Exchange (交换器):用来接收消息生产者所发送的消息井将这些消息路由给服务器中的队列。
  • Binding (绑定) 用于消息队列和交换器之间的关联。 个绑定就是基于路由键将交换器和消息队列连接起来的路由规则,所以以将交换器理解成 个由绑定构成的路由表
  • Virtual Host (虚拟主机):它是消息队列以及相关对象的集合,是共享同一个身份验证和加密环境的独 服务器域。每个虚拟主本质上都是 mini 版的消息服务器,拥有自己的队列、交换器、绑定和权限机制。
  • Broker (消息代理) 表示消息队列服务器实体,接受客户端连接,实现 AMQP 消息队列和路由功能的过程
  • Routing Key (路由规则〉:虚拟机可用它来确定如何路由一个特定消息。
  • Queue (消息队列):用来保存消息直到发送给消费者。它是消息的容器,也是消息的终点。一个消息可被投入 个或多个队中息一直在队列里面,等待消费者连接到这个队列将其取走。
  • Connection (连接〉 可以理解成客户端和消息队列服务器之间的 TCP 连接
  • Channel (信道):仅仅当创建了连接后,若客户端还是不能发送消息,则需要为连接创建一个信道。信道是 条独立的双向数流通道,它是建立在真实的 TCP 连接内的虚拟连接, AMQP 令都是通过信道发出去的,不管是发布消息、订阅队列还是接收消息,它们都通过信道完成。 个连接可以包含多个信道,之所以需要信道,==是因为TCP 接的建立和释放都是 分昂贵的,==如果客户端的每 个线程都需要与消息服务器交互,如果每 个线程都建立了 TCP 连接,暂且不考虑 TCP 接是否?浪费,就算操作系统也无法承受每秒建立如此多的 TCP 连接
核心组件的生命周期

在这里插入图片描述
(1 )消息的生命周期

生产者( Publisher )在发布消息时可 给消息指定各种消息属性( message meta-data ),其中有些属性有可能会被消息代理( Broker )所使用,而其他属性则是完全不透明的, 们只能被接收消息的应用所使用。当消息到达服务器时,交换器通常会将消息路由到服务器上的消息队列中,如果消息不能路由,则交换器会将消息丢弃或者将其返回给生产者,这样生产者可以选择如何来处理未路由的消息。单条消息可存在于多个消息队列中 ,消息代理可以采用 复制消息等多种方式进行处理。但是当 条消息被路由到多个消息队列中时,它在每个消息队列中都是一样 。当消息到达消息队列时,==消息队列会 尝试将消息传递给消息消费者。如果传递不成功 ,则消息队列会存储消息(按生产者要求存在者 内存或磁盘中),并 待消 费者准备好。==如果没有消费者,则消息队列通过 AMQP 将消息返回给生产者( 如果需要的话) 。当消息队列把消息传递给消费者后 ,它 从内部 中删除消息,删除动作可能是 发生的, 可能在消费者应答 己成功处理之后再删除。消息消费者可选择如何及何时来应答消息,同 消费者也可以拒绝消息 (一个否定应答〉。

(2)交换器的生命周期
每台 AMQP 务器都预先 建了许多交换器实例,它们在服务器启动时就存在并且不能被销毁 如果你的应用程序有特殊要求,则可以选择自己创建交换器,并在完成工作后进行销毁
(3)队列的生命周期
这里主要有两种消 队列的生命周期,即持久化消息队列和临时消息队列。持久化消息队列可被 个消费者共享 不管是否有消费者接收,它们都可 以独立存 临时消 队列对消费者是私有的,只能绑定到此消费者,当消费者断开连接时,该消息队列将被删除。

MQTT 协议

它是一个基于TCP IP 协议、可提供发布/订阅消息模式、十分轻量级的通信协议。除标准版外,还有 个简化版本MQTT SN ,它基于非 TCP IP 协议(如 ZigBee 协议),该协议主要为嵌入式设备提供消息通信。这里主要介绍标准版 MQTT 3.1.1 ,该协议是一个基于客户端-服务器的消息发布/订阅传输协议,其特点是轻量、简单、开放和易于实现。正因为这些特点,使它常应用于很多机器计算能力有限、低带宽、网络不可 的远程通信应用场景中。
目前有很多 MQT 消息中间件服务器,如下都是 MQTT 协议的服务器端的实现
IBM WebSphere MQ Teleme IBM MessageSig Mosquitto clipse ho emqttd Xively
m2m.io webMethods Nirvana Messa ing == RabbitMQ pache ActiveMQ == Apache Apollo
Moque仗队 HiveMQ Mosca Litmus Automation Loop JoramMQ hingMQ VemeMQ

主要概念

所有基于 网络连接的应用都会有客户端( Client )和服务器( Server ),而在 MQTT 协议使用者有 种身份: 发布者( Publisher )、代理( Broker )和订阅者( Subscriber )。其中消息的发布者和 订阅者都是客户端,消息代理是服务器 消息发布者可以同时是订阅者。

一条消息 流转过程是这样的 先由消息发布者发布消息到代理服务器,在消息中会包含
主题( Topic ),之后消息订阅者如果订阅了该主题的消息,将会收到代理服务器推送的消息

在这里插入图片描述

MQTT 协议中的 组件

  • 网络连接( Network Connection ):网络连接 客户端连接到服务器时所使 有的底层传输协议,由该连接来负责提供有序的、可靠的基于字节流的双向传输
  • 应用消息( ppli cat ion Message ):应用消息指通过网络所传输的应用数据,该数据 般包括 题和负载两部分。
  • 主题( Topic):主题题相当于应用消息的类型 ,消息订阅者订阅后,就会收到该主题的消 内容
  • 负载( Payload): 负载指消息订阅者具体接收的内容
  • 客户端(Client)客户端指使用 MQTT 程序或设备 客户端总是通过网络连接到服务端,它可以发布应用消息给其他相关的客端、订阅消息用以请求接收相关的应用消息、取消订阅应用消息、从服务器断开连接等。
  • 服务器( Server):服务器也是指程序或设备,它作为发送消息的客户端束 请求订阅的客户端之间的中介。服务器的功能包括接收来自客户端的网络连接、接收客户端发布的应用消息、处理客户端的订阅和取消订阅的请求、转发应用消息给相应的客户端等
  • 会话( Sess on):客户端与服务器建立连接之后就是 个会话,客户端和服务器之间通过会话来进行状态交互。会话存在于一个网络连接之间,也可能会跨越多个连续的网络连接。会话主要用于客户端和服务器之间的逻辑层面的通信
  • 订阅( Su scripti on):订阅一般与 个会话关联,会话可以包含多于 个的订阅。订阅包含 个主题过滤器和个服务质量( QoS )等级。会话的每个订阅都有 个不同的主题过滤器。
  • 主题名( opic Name):主题名是附加在消息上的一个标签,该标签与服务器的订阅相匹配,服务器会根据该标签将消息发送给与订阅所匹配的每个客户端
  • 主题过滤器( pi Filter):主题过滤器是订阅中包含的一个表达式,用于表示相关联的一个或多个主题。主题过滤器可以使用通配衍。
  • MQTT 控制拇文 CMQT Control Packet):MQT 控制报文实际上就是通过网络连接发送的信息数据包。

STOMP 协议

STOMP ( Streaming Text Orientated Messaging Protocol 流文本定向消息协议〉是 个简单
的文本消息传输协议, 它提供了 种可互操作的连接格式,允许客户端与任意消息服务器
Broker )进行交互 如下都 STOMP
协议的服务器端实现。
Apache Apollo Apach ActiveMQ RabbitMQ Horn tQ Sta mpy StompServer

主要概念

与其他消 协议相 同, STOMP 同样包含客户端和服务器,这里的客户端既可以是消息生产者,也可以是消息梢费者,而服务器就是消息数据的目的地,所有消息都会被发送到服务器
在这里插入图片描述
STOMP 客户端和服务器之间的通信是基于 来实现的 每一 都包括一 表示命令
符串、一系列可选的 头条目和帧的数据内容。帧的数据格式如下
在这里插入图片描述

JMS 协议

JMS CJava Message Service) ep Java 消息服务应用程序接口,是 Ja 平台中面向消息中间
件的 套规范的 JavaAP 接口,用于在两个应用程序之间或分布式系统中发送消息,进行异步
通信 这套规范由 IB 提出
jms并不是消息队列协议的 种,更不是消息队列产品,它是与具体平台无关 API 目前市
面上的绝大多数消息中间件厂商都支持 接口规范 换句话说 你可 使用 JMSAPI 来连接
支持 AMQP STOMP 等协议的消息中间件产品(比如 Act veM RabbitMQ 等),在这一点上
它与 Java 中的 IDB 的作用很像,我们可以用 IDB CAPI 来访问具体的数据库产品( Oracle
My 等)。

体系架构

JMS 之前,大部分消息队列产品都支持点对点 发布 订阅两种方式来传递消息。基于
此, JMS 将这两种消息模型抽象成两类规范,它们相互独立,由 JMS 的提供商(即消息队列产
品的具体厂商〉自己选择实现其中的 种还是两 模型。 JMS 的作用是提供通用接口保证基于
JMS PI 编写 程序适用于任何 种模型 使得在更换消息队列提供商 况下 程序
代码也不需要做太大 改动。

(1 ) 点对点模型在点对点( Point to int )模型中,应用程序由队列( Queue )、发送者( Sender )和接
(Receiver )组成。每条消息都被发送到一个特定的队列中,接收者从队列中获取消息( )。
队列中 直保留着消息,直到它们被接收或超时。点对点模型的特点如下:

  • 每条消息只有一个接收者,消息一旦被接收就不再保留在消息队列中了。
  • 发送者 接收者之间在时间上没有依赖。也就是说,当消息被发送之后 不管接收者有没有在运行,都不会影响消息被发送到队列中。
  • 每条消息仅会被传送给 个接收者 也就是说, 个队列中可能会有多个接收者听,但是消息只能被队列中的 个接收者接收
  • 消息存在先后顺序 。一个队列会按照消息服务器将消息放入队列中的顺序把它们传送给接收者。当消息己经被接收时就会从队列头部将它们删除(除非使用了消息优先级)
  • 当接收者收 消息时,会发送确认收到通知

所以,一般情况下,如果希望所发送的每条消息都能被成功处理,则需要使用点对点模型

在这里插入图片描述
(2 )发布/订阅模型
在发布/订阅( Pub Sub )模型中,应用程序由主题( Topic )、发布者( Publi )和订阅者
Subsc )组成。发布者发布 条消息,该消息通过 题传递给所有的订阅者
在这种模型中,发布者和订阅者彼此不知道对方,它们是匿名的井且可以动态发布和订阅主题。
主题用于保存和传递消息,并且会 直保存消息直到消息被传递给订阅者。
在这里插入图片描述
发布/订阅模型的特点如下:

  • 每条消息可以有多个订阅者
  • 发布者和订阅者之间有时间上的依赖 一般情况下,某个主题的订阅者需要在创建了订阅之后才能接收到消息,而且为了接收消息订阅者必须保持运行的状态。
  • JMS 允许订阅者创建 可持久化的订阅,这样即使订阅者没有运行也能接收到所阅的消息
  • 每条消息都会传送给该主题下的所有 订阅者
  • 通常发布者不会知道 意识不到哪一个订阅者正在接收消息所以,如果希望所发送的消息不被做任何处理或者被 个或多个订阅者 ,则可以使用发布/订阅模型。

基本概念

按照、JMS 规范中所说的, 一个JMS 应用由如下几个部分组成

  • JMS 客户端( JMS Client): 指发送和接收消息的 Java 程序
  • 非JMS 客户端(Non JMS Client ):指使用消息系统原生 客户端 API 代替 JMS 的客户端。 果应用程序在 JMS 规范前就己存在, 它可能同时包 JMS 客户端 JMS客户端。
  • 消息( Message) 每个应用都定义了一组消息,用于多 客户端之间的消息通信
  • JMS 提供商( JMS Provider ):指实现了 JMS API 实际消息系统。
  • 受管对象( Administered Obect :指由 管理员创建, 并预先 好给客户端使用的血但对象。 JMS 中的受管对象分为两种,即 ConnectionFactory (客户端使用这个对象来建到提供者的连接)和 Destination (客户端使用这个对象来指定发送或接收消息的目
    的地)。

具体到 JMS 应用程序, 主要涉及以 基本概念

  • 生产者( Producer 建并发送消息 JMS 客户端,在点对点模型中就是发送者 ,在发布/订阅模型中就是发布者
  • 消费者( Consumer ): 接收消息的 JMS 客户端 在点对点模型中就是接收者 在发订阅模型中就是订阅者。
  • 客户端( lient ):生产或消费消息的基于 Jav 应用程序或对象。
  • 队列( Queue 个容纳被发送的等待阅读的消息的区域。它是点对点模型中的队列。
  • 主题( Topic ):一种支持发送消息给多个订阅者的机制。它是发布/订阅模型中的主题。
  • 在 JMS 客户端之间传递的数据对象。 JMS 消息又包括消息头、属性和消息体 部分。消息头是指所有消息都支持的相同的头字段集,它包含了客户端JMS 提供商都要使用的用于标识和路由消息的值 属性是指除标准的头宇段外,消息接口还 含了 支持属性值的内建机制 实际上,这 是为消息提供了 加可选的消息头字段的机制。消息属性包括应用专有属性、标准属性、提供商专有属性
    JMS 定义了几种消息体类型,这些类型覆盖了当前使用的大部分消息风格。消息体就是指实际的消息内容。

编程接口

ConnectionFactory 接口(连接工厂〉
ConnectionFactory onnection 工厂,根据不同的消息类型用户可选择用队列
连接工厂或者主题连接 厂,分别对应 QueueConnecti onF actory TopicConnectionFactory
以通过 JNDI 来查找 ConnectionFactory 对象。

Destination 接口(目的地)
Destination 是一 包装了消息目的地标识符的受管对象 消息目的地是指消息发布和接收的地点,消息目的地要么是队列要么是主题。对于消息生产者来说 ,它的 Destination 是某个队列或某个主题:对于消息消费者来说,它的 Destination 是某个队列或主题( 即消息来源)。所以 Destination 实际上就是两种类型的对象 Queue Topic 可以通过 JNDI 来查找 Destination

Connection 接口(连接)
Connection 表示在客户端和 JMS 系统之 建立的连接(实际上是对 TCP IP Socket 的包装)。
Connection 可以产生 个或多个 Session ,跟 ConnectionFactory 样, onnection 有两 类型
QueueConnection TopicConnection

Session 接口(会话)
Session 是实际操作消息的接口,表示一 单线程的上下文,用于发送和接 消息。因为会
话是单线程的,所以消息是按照发送的顺序 个个接收的 。可 以通过 Session 创建生产者、消费
者、消息等。在规范 Session 还提供了事务的功能。 Session 分为两种类型 QueueSession
军日 TopicSession

MessageProducer 接口(消息生产者〉
消息生产者由 Session 创建并用于将消息发送到 Destination 消费者可以 步(阻塞模式)
或异步(非阻塞模式)接收队列和主题类型的消息。消息生产者有两种类型 QueueSender
TopicPublisher

MessageConsumer 接口(消息消费者)
消息消费者由 Session 建,用于接收被发送到 Destination 的消息。消息、消费者有两种类刑
QueueReceiver TopicSubscriber

Message 接口(消息〉
消息是在 费者 生产者之 传送 对象,即将消 应用程序发送 应用程序。

MessageListener (消息监 器)
如果果注册 消息监听 那么当消息 将自动调用监 onMessage 方法。

总结

在使用消息队列时肯定需要了JMS ,该规范实际上是对 AMQPMQTT STOMP XMPP 等消息通信协议的更高 层的抽象 从消息队列使用者的角度来看,JMS 对所需要 理的常规 题都已经提供了相关支持
节选自-------《分布式消息中间件实践》 可以在脚本之家下载

Logo

为开发者提供学习成长、分享交流、生态实践、资源工具等服务,帮助开发者快速成长。

更多推荐