消息队列及消息中间件

╰半橙微兮° 2022-05-16 23:09 286阅读 0赞

**消息队列** 已经逐渐成为企业应用系统 **内部通信** 的核心手段。它具有 **低耦合**、**可靠投递**、**广播**、**流量控制**、**最终一致性** 等一系列功能。

当前使用较多的 **消息队列** 有 RabbitMQ、RocketMQ、ActiveMQ、Kafka、ZeroMQ、MetaMQ 等，而部分 **数据库** 如 Redis、MySQL 以及 phxsql 也可实现消息队列的功能。

![细说消息队列及消息中间件][1531722845588852fe1b952]

# 正文 #

1. 消息队列概述

**消息队列** 是指利用 **高效可靠** 的 **消息传递机制** 进行与平台无关的 **数据交流**，并基于 **数据通信**来进行分布式系统的集成。

![细说消息队列及消息中间件][153172284562341850c50d9]

通过提供 **消息传递** 和 **消息排队** 模型，它可以在 **分布式环境** 下提供 **应用解耦**、**弹性伸缩**、**冗余存储**、**流量削峰**、**异步通信**、**数据同步** 等等功能，其作为 **分布式系统架构** 中的一个重要组件，有着举足轻重的地位。

2. 消息队列的特点

2.1. 采用异步处理模式

**消息发送者** 可以发送一个消息而无须等待响应。**消息发送者** 将消息发送到一条 **虚拟的通道**（**主题** 或 **队列**）上，**消息接收者** 则 **订阅** 或是 **监听** 该通道。一条信息可能最终转发给 **一个或多个** 消息接收者，这些接收者都无需对 **消息发送者** 做出 **同步回应**。整个过程都是 **异步的**。

2.2. 应用系统之间解耦合

主要体现在如下两点：

1.  发送者和接受者不必了解对方、只需要 **确认消息**；
2.  发送者和接受者 **不必同时在线**。

比如在线交易系统为了保证数据的 **最终一致**，在 **支付系统** 处理完成后会把 **支付结果** 放到 **消息中间件** 里，通知 **订单系统** 修改 **订单支付状态**。两个系统是通过消息中间件解耦的。

3. 消息队列的传递服务模型

消息队列的 **传递服务模型** 如下图所示：

![细说消息队列及消息中间件][1531722844123020fbb9f3d]

4. 消息队列的的传输模式

4.1. 点对点模型

**点对点模型** 用于 **消息生产者** 和 **消息消费者** 之间 **点到点** 的通信。消息生产者将消息发送到由某个名字标识的特定消费者。这个名字实际上对于消费服务中的一个 **队列**（Queue），在消息传递给消费者之前它被 **存储** 在这个队列中。**队列消息** 可以放在 **内存** 中也可以 **持久化**，以保证在消息服务出现故障时仍然能够传递消息。

传统的点对点消息中间件通常由 **消息队列服务**、**消息传递服务**、**消息队列** 和 **消息应用程序接口** API 组成，其典型的结构如下图所示。

![细说消息队列及消息中间件][15317228439771894738e2e]

**特点：**

1.  每个消息只用一个消费者；
2.  发送者和接受者没有时间依赖；
3.  接受者确认消息接受和处理成功。

**示意图如下所示：**

![细说消息队列及消息中间件][1531722845724057931a7fa]

4.2. 发布/订阅模型（Pub/Sub）

**发布者/订阅者** 模型支持向一个特定的 **消息主题** 生产消息。0 或 **多个订阅者** 可能对接收来自 **特定消息主题** 的消息感兴趣。

在这种模型下，发布者和订阅者彼此不知道对方，就好比是匿名公告板。这种模式被概况为：多个消费者可以获得消息，在 **发布者** 和 **订阅者** 之间存在 **时间依赖性**。发布者需要建立一个 **订阅**（subscription），以便能够消费者订阅。**订阅者** 必须保持 **持续的活动状态** 并 **接收消息**。

在这种情况下，在订阅者 **未连接时**，发布的消息将在订阅者 **重新连接** 时 **重新发布**，如下图所示：

![细说消息队列及消息中间件][15317228456007854a05b60]

**特性：**

1.  每个消息可以有多个订阅者；
2.  客户端只有订阅后才能接收到消息；
3.  持久订阅和非持久订阅。

> 注意：

*  发布者和订阅者有时间依赖：接受者和发布者只有建立订阅关系才能收到消息；
 *  持久订阅：订阅关系建立后，消息就不会消失，不管订阅者是否都在线；
 *  非持久订阅：订阅者为了接受消息，必须一直在线。 当只有一个订阅者时约等于点对点模式

5. 消息队列应用场景

当你需要使用 **消息队列** 时，首先需要考虑它的必要性。可以使用消息队列的场景有很多，最常用的几种，是做 **应用程序松耦合**、**异步处理模式**、**发布与订阅**、**最终一致性**、**错峰流控** 和 **日志缓冲** 等。反之，如果需要 **强一致性**，关注业务逻辑的处理结果，则使用 RPC 显得更为合适。

5.1. 异步处理

**非核心** 流程 **异步化**，减少系统 **响应时间**，提高 **吞吐量**。例如：**短信通知**、**终端状态推送**、App **推送**、**用户注册** 等。

**消息队列** 一般都内置了 **高效的通信机制**，因此也可以用于单纯的消息通讯，比如实现 **点对点消息队列** 或者 **聊天室** 等。

应用案例

网站用户注册，注册成功后会过一会发送邮件确认或者短息。

![细说消息队列及消息中间件][1531722844003beaf111218]

5.2. 系统解耦

*  系统之间不是 **强耦合的**，**消息接受者** 可以随意增加，而不需要修改 **消息发送者的代码**。**消息发送者** 的成功不依赖 **消息接受者**（比如：有些银行接口不稳定，但调用方并不需要依赖这些接口）。
 *  **不强依赖** 于非本系统的核心流程，对于 **非核心流程**，可以放到消息队列中让 **消息消费者** 去按需消费，而 **不影响核心主流程**。

5.3. 最终一致性

**最终一致性** 不是 **消息队列** 的必备特性，但确实可以依靠 **消息队列** 来做 **最终一致性** 的事情。

*  **先写消息再操作**，确保操作完成后再修改消息状态。**定时任务补偿机制** 实现消息 **可靠发送接收**、业务操作的可靠执行，要注意 **消息重复** 与 **幂等设计**。
 *  所有不保证 100% **不丢消息** 的消息队列，理论上无法实现 **最终一致性**。

> 像 Kafka 一类的设计，在设计层面上就有 **丢消息** 的可能（比如 **定时刷盘**，如果掉电就会丢消息）。哪怕只丢千分之一的消息，业务也必须用其他的手段来保证结果正确。

5.4. 广播

**生产者/消费者** 模式，只需要关心消息是否 **送达队列**，至于谁希望订阅和需要消费，是 **下游**的事情，无疑极大地减少了开发和联调的工作量。

![细说消息队列及消息中间件][1531722844940cecdc7374e]

5.5. 流量削峰和流控

当 **上下游系统** 处理能力存在差距的时候，利用 **消息队列** 做一个通用的 **“漏斗”**，进行 **限流控制**。在下游有能力处理的时候，再进行分发。

> 举个例子：用户在支付系统成功结账后，订单系统会通过短信系统向用户推送扣费通知。 **短信系统** 可能由于 **短板效应**，速度卡在 **网关** 上（每秒几百次请求），跟 **前端的并发量** 不是一个数量级。 于是，就造成 **支付系统** 和 **短信系统** 的处理能力出现差异化。

然而用户晚上个半分钟左右收到短信，一般是不会有太大问题的。如果没有消息队列，两个系统之间通过 **协商**、**滑动窗口** 等复杂的方案也不是说不能实现。但 **系统复杂性** 指数级增长，势必在 **上游** 或者 **下游** 做 **存储**，并且要处理 **定时**、**拥塞** 等一系列问题。而且每当有 **处理能力有差距** 的时候，都需要 **单独** 开发一套逻辑来维护这套逻辑。

所以，利用中间系统转储两个系统的通信内容，并在下游系统有能力处理这些消息的时候，再处理这些消息，是一套相对较通用的方式。

应用案例

1.  把消息队列当成可靠的 **消息暂存地**，进行一定程度的 **消息堆积**；
2.  定时进行消息投递，比如模拟 **用户秒杀** 访问，进行 **系统性能压测**。

![细说消息队列及消息中间件][153172284558518ae22ffaa]

5.6. 日志处理

将消息队列用在 **日志处理** 中，比如 Kafka 的应用，解决 **海量日志** 传输和缓冲的问题。

应用案例

把日志进行集中收集，用于计算 PV、**用户行为分析** 等等。

![细说消息队列及消息中间件][15317228440691f96f00dfe]

5.7. 消息通讯

消息队列一般都内置了 **高效的通信机制**，因此也可以用于单纯的 **消息通讯**，比如实现 **点对点消息队列** 或者 **聊天室** 等。

6. 消息队列的推拉模型

6.1. Push推消息模型

**消息生产者** 将消息发送给 **消息队列**，**消息队列** 又将消息推给 **消息消费者**。

6.2. Pull拉消息模型

**消费者** 请求 **消息队列** 接受消息，**消息生产者** 从 **消息队列** 中拉该消息。

6.3. 两种类型的区别

![细说消息队列及消息中间件][153172338578697cbd37f67]

7. 消息队列技术对比

本部分主要介绍四种常用的消息队列（ActiveMQ / RabbitMQ / RocketMQ / Kafka）的主要特性、优点、缺点。

7.1. ActiveMQ

ActiveMQ 是由 Apache 出品，ActiveMQ 是一个完全支持JMS1.1 和 J2EE 1.4 规范的 JMS Provider 实现。它非常快速，支持 **多种语言的客户端** 和 **协议**，而且可以非常容易的嵌入到企业的应用环境中，并有许多高级功能。

![细说消息队列及消息中间件][153172339612436a649367c]

(a) 主要特性

1.  **服从JMS规范**：JMS 规范提供了良好的标准和保证，包括：**同步** 或 **异步** 的消息分发，一次和仅一次的消息分发，**消息接收** 和 **订阅** 等等。遵从 JMS 规范的好处在于，不论使用什么 JMS 实现提供者，这些基础特性都是可用的；
2.  **连接灵活性**：ActiveMQ 提供了广泛的 **连接协议**，支持的协议有：HTTP/S，IP **多播**，SSL，TCP，UDP 等等。对众多协议的支持让 ActiveMQ 拥有了很好的灵活性；
3.  **支持的协议种类多**：OpenWire、STOMP、REST、XMPP、AMQP；
4.  **持久化插件和安全插件**：ActiveMQ 提供了 **多种持久化** 选择。而且，ActiveMQ 的安全性也可以完全依据用户需求进行 **自定义鉴权** 和 **授权**；
5.  **支持的客户端语言种类多**：除了 Java 之外，还有：C/C++，.NET，Perl，PHP，Python，Ruby；
6.  **代理集群**：多个 ActiveMQ **代理** 可以组成一个 **集群** 来提供服务；
7.  **异常简单的管理**：ActiveMQ 是以开发者思维被设计的。所以，它并不需要专门的管理员，因为它提供了简单又使用的管理特性。有很多中方法可以 **监控** ActiveMQ 不同层面的数据，包括使用在 JConsole 或者在 ActiveMQ 的 Web Console 中使用 JMX。通过处理 JMX 的告警消息，通过使用 **命令行脚本**，甚至可以通过监控各种类型的 **日志**。

(b) 部署环境

ActiveMQ 可以运行在 Java 语言所支持的平台之上。使用 ActiveMQ 需要：

*  Java JDK
 *  ActiveMQ 安装包

1.  **跨平台** (JAVA 编写与平台无关，ActiveMQ 几乎可以运行在任何的 JVM 上)；
2.  可以用 JDBC：可以将 **数据持久化** 到数据库。虽然使用 JDBC 会降低 ActiveMQ 的性能，但是数据库一直都是开发人员最熟悉的存储介质；
3.  支持 JMS 规范：支持 JMS 规范提供的 **统一接口**;
4.  支持 **自动重连** 和 **错误重试机制**；
5.  有安全机制：支持基于 shiro，jaas 等多种 **安全配置机制**，可以对 Queue/Topic 进行 **认证和授权**；
6.  监控完善：拥有完善的 **监控**，包括 Web Console，JMX，Shell 命令行，Jolokia 的 RESTful API；
7.  界面友善：提供的 Web Console 可以满足大部分情况，还有很多 **第三方的组件** 可以使用，比如 hawtio；

(d) 缺点

1.  社区活跃度不及 RabbitMQ 高；
2.  根据其他用户反馈，会出莫名其妙的问题，会 **丢失消息**；
3.  目前重心放到 activemq 6.0 产品 Apollo，对 5.x 的维护较少；
4.  不适合用于 **上千个队列** 的应用场景；

7.2. RabbitMQ

RabbitMQ 于 2007 年发布，是一个在 AMQP (**高级消息队列协议**)基础上完成的，可复用的企业消息系统，是当前最主流的消息中间件之一。

![细说消息队列及消息中间件][15317228441737abea255d3]

(a) 主要特性

1.  **可靠性**：提供了多种技术可以让你在 **性能** 和 **可靠性** 之间进行 **权衡**。这些技术包括 **持久性机制**、**投递确认**、**发布者证实** 和 **高可用性机制**；
2.  **灵活的路由**：消息在到达队列前是通过 **交换机** 进行 **路由** 的。RabbitMQ 为典型的路由逻辑提供了 **多种内置交换机** 类型。如果你有更复杂的路由需求，可以将这些交换机组合起来使用，你甚至可以实现自己的交换机类型，并且当做 RabbitMQ 的 **插件**来使用；
3.  **消息集群**：在相同局域网中的多个 RabbitMQ 服务器可以 **聚合** 在一起，作为一个独立的逻辑代理来使用；
4.  **队列高可用**：队列可以在集群中的机器上 **进行镜像**，以确保在硬件问题下还保证 **消息安全**；
5.  **支持多种协议**：支持 **多种消息队列协议**；
6.  **支持多种语言**：用 Erlang 语言编写，支持只要是你能想到的 **所有编程语言**；
7.  **管理界面**： RabbitMQ 有一个易用的 **用户界面**，使得用户可以 **监控** 和 **管理** 消息 Broker 的许多方面；
8.  **跟踪机制**：如果 **消息异常**，RabbitMQ 提供消息跟踪机制，使用者可以找出发生了什么；
9.  **插件机制**：提供了许多 **插件**，来从多方面进行扩展，也可以编写自己的插件。

(b) 部署环境

RabbitMQ 可以运行在 Erlang 语言所支持的平台之上，包括 Solaris，BSD，Linux，MacOSX，TRU64，Windows 等。使用 RabbitMQ 需要：

*  ErLang 语言包
 *  RabbitMQ 安装包

1.  由于 Erlang 语言的特性，消息队列性能较好，支持 **高并发**；
2.  健壮、稳定、易用、**跨平台**、支持 **多种语言**、文档齐全；
3.  有消息 **确认机制** 和 **持久化机制**，可靠性高；
4.  高度可定制的 **路由**；
5.  **管理界面** 较丰富，在互联网公司也有较大规模的应用，社区活跃度高。

(d) 缺点

1.  尽管结合 Erlang 语言本身的并发优势，性能较好，但是不利于做 **二次开发和维护**；
2.  实现了 **代理架构**，意味着消息在发送到客户端之前可以在 **中央节点** 上排队。此特性使得 RabbitMQ 易于使用和部署，但是使得其 **运行速度较慢**，因为中央节点 **增加了延迟**，**消息封装后** 也比较大；
3.  需要学习 **比较复杂** 的 **接口和协议**，学习和维护成本较高。

7.3. RocketMQ

RocketMQ 出自 **阿里** 的开源产品，用 Java 语言实现，在设计时参考了 Kafka，并做出了自己的一些改进，**消息可靠性上** 比 Kafka 更好。RocketMQ 在阿里内部被广泛应用在 **订单**，**交易**，**充值**，**流计算**，**消息推送**，**日志流式处理**，binglog **分发** 等场景。

(a) 主要特性

![细说消息队列及消息中间件][1531722844137ad46da8e73]

1.  基于 **队列模型**：具有 **高性能**、**高可靠**、**高实时**、**分布式** 等特点；
2.  Producer、Consumer、**队列** 都支持 **分布式**；
3.  Producer 向一些队列轮流发送消息，**队列集合** 称为 Topic。Consumer 如果做 **广播消费**，则一个 Consumer 实例消费这个 Topic 对应的 **所有队列**；如果做 **集群消费**，则 **多个** Consumer 实例 **平均消费** 这个 Topic 对应的队列集合；
4.  能够保证 **严格的消息顺序**；
5.  提供丰富的 **消息拉取模式**；
6.  高效的订阅者 **水平扩展**能力；
7.  **实时** 的 **消息订阅机制**；
8.  亿级 **消息堆积** 能力；
9.  较少的外部依赖。

(b) 部署环境

RocketMQ 可以运行在 Java 语言所支持的平台之上。使用 RocketMQ 需要：

*  Java JDK
 *  安装 git、Maven
 *  RocketMQ 安装包

1.  **单机** 支持 1 万以上 **持久化队列**；
2.  RocketMQ 的所有消息都是 **持久化的**，先写入系统 PAGECACHE，然后 **刷盘**，可以保证 **内存** 与 **磁盘** 都有一份数据，而 **访问** 时，直接 **从内存读取**。
3.  模型简单，接口易用（JMS 的接口很多场合并不太实用）；
4.  **性能非常好**，可以允许 **大量堆积消息** 在 Broker 中；
5.  支持 **多种消费模式**，包括 **集群消费**、**广播消费**等；
6.  各个环节 **分布式扩展设计**，支持 **主从** 和 **高可用**；
7.  开发度较活跃，版本更新很快。

(d) 缺点

1.  支持的 **客户端语言** 不多，目前是 Java 及 C++，其中 C++ 还不成熟；
2.  RocketMQ 社区关注度及成熟度也不及前两者；
3.  没有 Web 管理界面，提供了一个 CLI (命令行界面) 管理工具带来 **查询**、**管理** 和 **诊断各种问题**；
4.  没有在 MQ 核心里实现 JMS 等接口；

7.4. Kafka

Apache Kafka 是一个 **分布式消息发布订阅** 系统。它最初由 LinkedIn 公司基于独特的设计实现为一个 **分布式的日志提交系统** (a distributed commit log)，之后成为 Apache 项目的一部分。Kafka **性能高效**、**可扩展良好** 并且 **可持久化**。它的 **分区特性**，**可复制** 和 **可容错** 都是其不错的特性。

![细说消息队列及消息中间件][153172284405265f2415cd9]

(a) 主要特性

1.  **快速持久化**：可以在 O(1) 的系统开销下进行 **消息持久化**；
2.  **高吞吐**：在一台普通的服务器上既可以达到 10W/s 的 **吞吐速率**；
3.  **完全的分布式系统**：Broker、Producer 和 Consumer 都原生自动支持 **分布式**，自动实现 **负载均衡**；
4.  支持 **同步** 和 **异步** 复制两种 **高可用机制**；
5.  支持 **数据批量发送** 和 **拉取**；
6.  **零拷贝技术(zero-copy)**：减少 IO 操作步骤，提高 **系统吞吐量**；
7.  **数据迁移**、**扩容** 对用户透明；
8.  **无需停机** 即可扩展机器；
9.  **其他特性**：丰富的 **消息拉取模型**、高效 **订阅者水平扩展**、实时的 **消息订阅**、亿级的 **消息堆积能力**、定期删除机制；

(b) 部署环境

使用 Kafka 需要：

*  Java JDK
 *  Kafka 安装包

1.  **客户端语言丰富**：支持 Java、.Net、PHP、Ruby、Python、Go 等多种语言；
2.  **高性能**：单机写入 TPS 约在 100 万条/秒，消息大小 10 个字节；
3.  提供 **完全分布式架构**，并有 replica 机制，拥有较高的 **可用性** 和 **可靠性**，理论上支持 **消息无限堆积**；
4.  支持批量操作；
5.  **消费者** 采用 Pull 方式获取消息。**消息有序**，**通过控制** 能够保证所有消息被消费且仅被消费 **一次**；
6.  有优秀的第三方 Kafka Web 管理界面 Kafka-Manager；
7.  在 **日志领域** 比较成熟，被多家公司和多个开源项目使用。

(d) 缺点

1.  Kafka 单机超过 64 个 **队列/分区** 时，Load 时会发生明显的飙高现象。**队列** 越多，**负载** 越高，发送消息 **响应时间变长**；
2.  使用 **短轮询方式**，**实时性** 取决于 **轮询间隔时间**；
3.  消费失败 **不支持重试**；
4.  支持 **消息顺序**，但是 **一台代理宕机** 后，就会产生 **消息乱序**；
5.  社区更新较慢。

7.5. 几种消息队列对比

这里列举了上述四种消息队列的差异对比：

![细说消息队列及消息中间件][1531723301229012b04e072]

Kafka 在于 **分布式架构**，RabbitMQ 基于 AMQP **协议** 来实现，RocketMQ 的思路来源于 Kafka，改成了 **主从结构**，在 **事务性** 和 **可靠性** 方面做了优化。广泛来说，**电商**、**金融** 等对 **事务一致性** 要求很高的，可以考虑 RabbitMQ 和 RocketMQ，对 **性能要求高** 的可考虑 Kafka。

# 小结 #

本文介绍了消息队列的特点，消息队列的 **传递服务模型**，消息的 **传输方式**，消息的 **推拉模式**。然后介绍了 ActiveMQ，RabbitMQ，RocketMQ 和 Kafka 几种常见的消息队列，阐述了 **各种消息队列** 的 **主要特点** 和 **优缺点**。通过本文，对于消息队列及相关技术选型，相信你会有了更深入的理解和认识。更多细节和原理性的东西，还需在实践中见真知！

[1531722845588852fe1b952]: /images/20220517/285478515e4048aebb462175c2bc20fb.png
[153172284562341850c50d9]: http://p3.pstatp.com/large/pgc-image/153172284562341850c50d9
[1531722844123020fbb9f3d]: http://p3.pstatp.com/large/pgc-image/1531722844123020fbb9f3d
[15317228439771894738e2e]: /images/20220517/a1cbfd0bff50469abd6f44cbe55e174a.png
[1531722845724057931a7fa]: http://p3.pstatp.com/large/pgc-image/1531722845724057931a7fa
[15317228456007854a05b60]: http://p3.pstatp.com/large/pgc-image/15317228456007854a05b60
[1531722844003beaf111218]: http://p3.pstatp.com/large/pgc-image/1531722844003beaf111218
[1531722844940cecdc7374e]: http://p3.pstatp.com/large/pgc-image/1531722844940cecdc7374e
[153172284558518ae22ffaa]: /images/20220517/0439f4fc9c124f248e41de11d384601a.png
[15317228440691f96f00dfe]: http://p9.pstatp.com/large/pgc-image/15317228440691f96f00dfe
[153172338578697cbd37f67]: http://p3.pstatp.com/large/pgc-image/153172338578697cbd37f67
[153172339612436a649367c]: http://p9.pstatp.com/large/pgc-image/153172339612436a649367c
[15317228441737abea255d3]: http://p3.pstatp.com/large/pgc-image/15317228441737abea255d3
[1531722844137ad46da8e73]: /images/20220517/9c36fa3954964a5e9ccc8219211335ac.png
[153172284405265f2415cd9]: http://p3.pstatp.com/large/pgc-image/153172284405265f2415cd9
[1531723301229012b04e072]: /images/20220517/1c4ebcf7737741e38723190870ba8ecf.png