消息队列的使用场景是什么样的？

川长思鸟来 2022-09-13 13:27 222阅读 0赞

![7d17816f960da7b1db480a3e64ee11f1.gif][]

本文从异步、解耦、削峰填谷等核心应用场景，以及消息中间件常用协议、推拉模式对比来解答此问题。

什么是消息中间件

作为一种典型的消息代理组件（Message Broker），是企业级应用系统中常用的消息中间件，主要应用于分布式系统或组件之间的消息通讯，提供具有可靠、异步和事务等特性的消息通信服务。应用消息代理组件可以降低系统间耦合度，提高系统的吞吐量、可扩展性和高可用性。

分布式消息服务主要涉及五个核心角色，消息发布者（Publisher）、可靠消息组件（MsgBroker）、消息订阅者（Subscriber）、消息类型（Message Type）和订阅关系（Binding），具体描述如下：

1.  消息发布者，指发送消息的应用系统，一个应用系统可以发送一种或者多种消息类型，发布者发送消息到可靠消息组件 (MsgBroker)。
2.  可靠消息组件，即 MsgBroker，负责接收发布者发送的消息，根据消息类型和订阅关系将消息分发投递到一个或多个消息订阅者。整个过程涉及消息类型校验、消息持久化存储、订阅关系匹配、消息投递和消息恢复等核心功能。
3.  消息订阅者，指订阅消息的应用系统，一个应用系统可以订阅一种或者多种消息类型，消息订阅者收到的消息来自可靠消息组件 (MsgBroker)。
4.  消息类型：一种消息类型由 TOPIC 和 EVENTCODE 唯一标识。
5.  订阅关系，用来描述一种消息类型被订阅者订阅，订阅关系也被称为 Binding。

核心功能特色

可为不同应用系统间提供可靠的消息通信，降低系统间耦合度并提高整体架构的可扩展性和可用性。

可为不同应用系统间提供异步消息通信，提高系统吞吐量和性能。

发布者系统、消息代理组件以及订阅者系统均支持集群水平扩展，可依据业务消息量动态部署计算节点。

支持事务型消息，保证消息与本地数据库事务的一致性。

远程调用RPC和消息MQ区别

谈到消息队列，有必要看下RPC和MQ的本质区别，从两者的定义和定位来看，RPC（Remote Procedure Call）远程过程调用，主要解决远程通信间的问题，不需要了解底层网络的通信机制；消息队列（MQ）是一种能实现生产者到消费者单向通信的通信模型。核心区别在于RPC是双向直接网络通讯，MQ是单向引入中间载体的网络通讯。单纯去看队列，队列是一种特殊的线性表，特殊之处在于它只允许在表的前端（front）进行删除操作，而在表的后端（rear）进行插入操作，和栈一样，队列是一种操作受限制的线性表。进行插入操作的端称为队尾，进行删除操作的端称为队头。在队列前面增加限定词“消息”，意味着通过消息驱动来进行整体的架构实现。RPC和MQ本质上是网络通讯的两种不同的实现机制，RPC同步等待结果对比于MQ在异步、解耦、削峰填谷等上的特征显著差异主要有以下几点差异：

1.  在架构上，RPC和MQ的差异点是，Message有一个中间结点Message Queue，可以把消息存储起来。
2.  同步调用：对于要立即等待返回处理结果的场景，RPC是首选。
3.  MQ的使用，一方面是基于性能的考虑，比如服务端不能快速的响应客户端（或客户端也不要求实时响应），需要在队列里缓存；另外一方面，它更侧重数据的传输，因此方式更加多样化，除了点对点外，还有订阅发布等功能。
4.  随着业务增长，有的处理端调用下游服务太多或者处理量会成为瓶颈，会进行同步调用改造为异步调用，这个时候可以考虑使用MQ。

核心应用场景

针对MQ的核心场景，我们从异步、解耦、削峰填谷等特性进行分析，区别于传统的RPC调用。尤其在引入中间节点的情况下，通过空间（拥有存储能力）换时间（RPC同步等待响应）的思想，增加更多的可能性和能力。

#### **▐** **异步通信** ####

针对不需要立即处理消息，尤其那种非常耗时的操作，通过消息队列提供了异步处理机制，通过额外的消费线程接管这部分进行异步操作处理。

#### **▐** **解耦** ####

在应用和应用之间，提供了异构系统之间的消息通讯的机制，通过消息中间件解决多个系统或异构系统之间除了RPC之外另一种单向通讯的机制。

#### **▐** **扩展性** ####

因为消息队列解耦了主流程的处理过程，只要另外增加处理过程即可，不需要改变代码、不需要调整参数，便于分布式扩容。

#### **▐** **分布式事务一致性** ####

在2个应用系统之间的数据状态同步，需要考虑数据状态的最终一致性的场景下，利用消息队列所提供的事务消息来实现系统间的数据状态一致性。

#### **▐** **削峰填谷** ####

在访问量剧增的情况下，应用仍然需要继续发挥作用，但是这样的突发流量无法提前预知；如果为了能处理这类瞬间峰值访问提前准备应用资源无疑是比较大的浪费。使用消息队列在突发事件下的防脉冲能力提供了一种保障，能够接管前台的大脉冲请求，然后异步慢速消费。

#### **▐** **可****恢复性** ####

系统的一部分组件失效时，不会影响到整个系统。消息队列降低了应用间的耦合度，所以即使一个处理消息的应用挂掉，加入队列中的消息仍然可以在系统恢复后被处理。

#### **▐** **顺序保证** ####

####     ####

#### 在大多使用场景下，数据处理的顺序都很重要。大部分消息队列本来就是排序的，并且能保证数据会按照特定的顺序来进行处理。 ####

#### **▐** **大量堆积** ####

通过消息堆积能力处理数据迁移场景，针对旧数据进行全量迁移的同时开启增量消息堆积，待全量迁移完毕，再开启增量，保证数据最终一致性且不丢失。

#### **▐** **数据流处理** ####

分布式系统产生的海量数据流，如：业务日志、监控数据、用户行为等，针对这些数据流进行实时或批量采集汇总，然后导入到大数据实时计算引擎，通过消息队列解决异构系统的数据对接能力。

#### **▐** **业界消息中间件对比** ####

![919976e82e87f8d59e7be707ae0b0250.png][]

详细的对比可以参考：

https://blog.csdn.net/wangzhipeng47/article/details/107134024

消息中间件常用协议

#### **▐** **AMQP协议** ####

AMQP即Advanced Message Queuing Protocol,提供统一消息服务的高级消息队列协议,是应用层协议的一个开放标准,为面向消息的中间件设计。基于此协议的客户端与消息中间件可传递消息，并不受客户端/中间件不同产品，不同开发语言等条件的限制。  
优点：可靠、通用

#### **▐** **MQTT协议** ####

MQTT（Message Queuing Telemetry Transport，消息队列遥测传输）是IBM开发的一个即时通讯协议，成为物联网的重要组成部分。该协议支持所有平台，几乎可以把所有联网物品和外部连接起来，被用来当做传感器和致动器（比如通过Twitter让房屋联网）的通信协议。  
优点：格式简洁、占用带宽小、移动端通信、PUSH、嵌入式系统

#### **▐** **STOMP协议** ####

STOMP（Streaming Text Orientated Message Protocol）是流文本定向消息协议，是一种为MOM(Message Oriented Middleware，面向消息的中间件)设计的简单文本协议。STOMP提供一个可互操作的连接格式，允许客户端与任意STOMP消息代理（Broker）进行交互。  
优点：命令模式（非topic/queue模式）

#### **▐** **XMPP协议** ####

XMPP（可扩展消息处理现场协议，Extensible Messaging and Presence Protocol）是基于可扩展标记语言（XML）的协议，多用于即时消息（IM）以及在线现场探测。适用于服务器之间的准即时操作。核心是基于XML流传输，这个协议可能最终允许因特网用户向因特网上的其他任何人发送即时消息，即使其操作系统和浏览器不同。  
优点：通用公开、兼容性强、可扩展、安全性高，但XML编码格式占用带宽大

#### **▐** **基于TCP/IP自定义的协议** ####

有些特殊框架（如：redis、kafka、rocketMQ等）根据自身需要未严格遵循MQ规范，而是基于TCP/IP自行封装了一套二进制编解码协议，通过网络socket接口进行传输，实现了MQ的标准规范相关功能。

消息中间件推和拉模式对比

Push推模式：服务端除了负责消息存储、处理请求，还需要保存推送状态、保存订阅关系、消费者负载均衡；推模式的实时性更好；如果push能力大于消费能力，可能导致消费者崩溃或大量消息丢失

Push模式的主要优点是：

1.  对用户要求低，方便用户获取需要的信息
2.  及时性好，服务器端即时地向客户端推送更行的动态信息

Push模式的主要缺点是：

1.  推送的信息可能并不能满足客户端的个性化需求
2.  Push消息大于消费者消费速率额，需要有协调QoS机制做到消费端反馈

Pull拉模式：客户端除了消费消息，还要保存消息偏移量offset，以及异常情况下的消息暂存和recover；不能及时获取消息，数据量大时容易引起broker消息堆积。

Pull拉模式的主要优点是：

1.  针对性强，能满足客户端的个性化需求
2.  客户端按需获取，服务器端只是被动接收查询，对客户端的查询请求做出响应

Pull拉模式主要的缺点是：

1.  实时较差，针对于服务器端实时更新的信息，客户端难以获取实时信息
2.  对于客户端用户的要求较高，需要维护位点

#### **▐** **相关资料** ####

建议学习以下的技术文档，了解更多详细的技术细节和实现原理，加深对消息中间件的理解和应用，同时可以下载开源的源代码，本地调试相应的代码，加深对技术原理的理解和概念的掌握，以及在实际生产中更多的掌握不同的消息队列应用的场景下，高效和正确地使用消息中间件。

RocketMQ资料：

https://github.com/apache/rocketmq/tree/master/docs/cn

Kafka资料：

http://kafka.apache.org/documentation/\#introduction

阿里云RocketMQ文档：

https://help.aliyun.com/document\_detail/112010.html

赛事信息

正在进行中的“**2021第二届云原生编程挑战赛**”中有“**针对冷热读写场景的RocketMQ存储系统设计**”这个赛道，其中RocketMQ这个主题与本文内容息息相关。

看完这篇文章后，对此领域有兴趣的同学可以点击**阅读原文**，获取赛事相关信息。

✿ **拓展阅读**

[![35c74a92cc654c3b924c084964b4fa87.png][]][35c74a92cc654c3b924c084964b4fa87.png 1]

[![918e912c5e98cdefdd8c23606c2ff726.png][]][918e912c5e98cdefdd8c23606c2ff726.png 1]

**作者|**骨来

**编辑|**橙子君

**出品|**阿里巴巴新零售淘系技术

![70eeaa4f22e92d27dfb0e3148834bc79.png][]

![8430d50a5cefd7f508858ab61ee93a11.png][]

[7d17816f960da7b1db480a3e64ee11f1.gif]: /images/20220828/74d94d4591074e2a8b8040da2f118ca9.png
[919976e82e87f8d59e7be707ae0b0250.png]: /images/20220828/9b55da8f63e5472d8fa6e09674dae9f1.png
[35c74a92cc654c3b924c084964b4fa87.png]: /images/20220828/8b385e5a8b314198839a4d0637fcbb45.png
[35c74a92cc654c3b924c084964b4fa87.png 1]: http://mp.weixin.qq.com/s?__biz=MzAxNDEwNjk5OQ==&mid=2650433337&idx=1&sn=d5cf990d3478110e6f378ac303600e14&chksm=8396af21b4e1263765eb5f7b48bff3939cd091f0a5b878c30be67ff5f26f656ea230d668c0d2&scene=21#wechat_redirect
[918e912c5e98cdefdd8c23606c2ff726.png]: /images/20220828/c40643f0766a491a9dc5bcdfb50239f8.png
[918e912c5e98cdefdd8c23606c2ff726.png 1]: http://mp.weixin.qq.com/s?__biz=MzAxNDEwNjk5OQ==&mid=2650432277&idx=1&sn=3f1ec46156ff58d9a6a264170e81d851&chksm=8396ab0db4e1221bcfdc0cce9a09724b71e1e03a3ce607681cb2326957ddac4edf25571d6861&scene=21#wechat_redirect
[70eeaa4f22e92d27dfb0e3148834bc79.png]: /images/20220828/eedc7d370b9b458f8952ef0d56905fc8.png
[8430d50a5cefd7f508858ab61ee93a11.png]: /images/20220828/88276c4f295941198a83b4698a187947.png