消息队列（四）阿里RocketMQ

消息队列 RocketMQ 是阿里巴巴集团自主研发的专业消息中间件，基于高可用分布式集群技术，提供消息订阅和发布、消息轨迹查询以及定时（延时）消息、资源统计、监控报警等一系列消息云服务，是企业级互联网架构的核心产品。 消息队列 RocketMQ 历史超过9年，为分布式应用系统提供异步解耦、削峰填谷的能力，同时具备海量消息堆积、高吞吐、可靠重试等互联网应用所需的特性，是阿里巴巴双11使用的核心产品。

消息队列 RocketMQ 是阿里云正式商用的产品，目前在阿里云多个地域（Region）提供了高可用消息云服务，单个域内采用多机房部署，可用性极高，即使整个机房都不可用，仍然可以为应用提供消息发布服务，产品稳定性及可用性完全按照阿里巴巴内部标准来实施，无单点。

消息队列 RocketMQ 目前提供 TCP 和 HTTP 协议层面的接入方式，支持 Java 、C++、 .NET、 Go 、 Python 、Nodejs、 PHP 这七种编程语言，方便不同编程语言开发的应用快速接入消息队列 RocketMQ 消息云服务。 用户可以将应用部署在阿里云 ECS、企业自建云，或者嵌入到移动端、物联网设备中与消息队列 RocketMQ 建立连接进行消息收发，同时本地开发者也可以通过公网接入消息队列 RocketMQ 服务进行消息收发。

产品功能

消息队列 RocketMQ 提供了基于 TCP 和 HTTP 协议的多种编程语言的接入方式以及多维度的管理工具，同时针对不同的应用场景提供了一系列的特色功能。

功能概览图

多协议支持

• 支持 HTTP 协议：采用 RESTful 标准，方便易用，快速接入，跨网络能力强，并支持七种语言客户端。

• 支持 TCP 协议：区别于 HTTP 简单的接入方式，提供更为专业、可靠、稳定的 TCP 协议的 SDK 接入。

• 支持 STOMP 协议：类似于 HTTP 的纯文本的协议机制，常用于脚本语言（如 Ruby 、Python、Perl）和消息队列 RocketMQ Broker 进行轻量级交互。

管理工具

• Web 控制台：支持 Topic 管理、生产者管理、消费者管理、消息查询、消息轨迹展示和查询、资源报表以及监控报警管理。

• OpenAPI：提供 API 便于将消息队列 RocketMQ 管理 工具 集成到自己的控制台。

• mqadmin 命令集：专有云输出提供一套丰富的管理命令集，以命令方式对消息队列 RocketMQ 服务进行管理。

特色功能

• 事务消息：实现类似 X/Open XA 的分布事务功能，以达到事务最终一致性状态。

• 定时（延时）消息：允许消息生产者指定消息进行定时（延时）投递，最长支持 40 天。

• 大消息：支持最大 4 MB 消息。

• 消息轨迹：通过消息轨迹，能清晰定位消息从发布者发出，经由消息队列 RocketMQ 服务端，投递给消息订阅者的完整链路，方便定位排查问题。

• 广播消费：允许同一个 Group ID 所标识的所有 Consumer 都各自消费某条消息一次。

• 顺序消息：允许消息消费者按照消息发送的顺序对消息进行消费。

• 重置消费进度：根据时间重置消费进度，允许用户进行消息回溯或者丢弃堆积消息。

• 死信队列：将无法正常消费的消息储存到特殊的死信队列供后续处理。

• 全球消息路由：用于全球不同地域之间的消息同步复制，保证地域之间的数据一致性。

专有云部署

• 专家定制：提供技术方案设计；专家现场技术支持与培训。

• 灵活部署：支持专有云独立部署，同时支持混合云架构。

• 运维管控：专有云支持 mqadmin 命令集、Open API

• 运维管理工具，方便管控平台集成以及统一运维。

消息收发模型

消息队列 RocketMQ 支持“发布/订阅”模型，消息发布者（生产者）可以将一条消息发送服务端的某个主题（Topic），多个消息接收方（消费者）订阅这个主题以接收该消息，如下图所示：

Topic

消息主题，一级消息类型，通过 Topic 对消息进行分类。

Message

消息，消息队列中信息传递的载体。

Message ID

消息的全局唯一标识，由消息队列 RocketMQ 系统自动生成，唯一标识某条消息。

Message Key

消息的业务标识，由消息生产者（Producer）设置，唯一标识某个业务逻辑。

Tag

消息标签，二级消息类型，用来进一步区分某个 Topic 下的消息分类

Producer

消息生产者，也称为消息发布者，负责生产并发送消息。

Producer 实例

Producer 的一个对象实例，不同的 Producer 实例可以运行在不同进程内或者不同机器上。Producer 实例线程安全，可在同一进程内多线程之间共享。

Consumer

消息消费者，也称为消息订阅者，负责接收并消费消息。

Consumer 实例

Consumer 的一个对象实例，不同的 Consumer 实例可以运行在不同进程内或者不同机器上。一个 Consumer 实例内配置线程池消费消息。

Group

一类 Producer 或 Consumer，这类 Producer 或 Consumer 通常生产或消费同一类消息，且消息发布或订阅的逻辑一致。

Group ID

Group 的标识。

Exactly-Once 投递语义

Exactly-Once 投递语义是指发送到消息系统的消息只能被消费端处理且仅处理一次，即使生产端重试消息发送导致某消息重复投递，该消息也在消费端也只被消费一次。

集群消费

一个 Group ID 所标识的所有 Consumer 平均分摊消费消息。例如某个 Topic 有 9 条消息，一个 Group ID 有 3 个 Consumer 实例，那么在集群消费模式下每个实例平均分摊，只消费其中的 3 条消息。

广播消费

一个 Group ID 所标识的所有 Consumer 都会各自消费某条消息一次。例如某个 Topic 有 9 条消息，一个 Group ID 有 3 个 Consumer 实例，那么在广播消费模式下每个实例都会各自消费 9 条消息。

定时消息

Producer 将消息发送到消息队列 RocketMQ 服务端，但并不期望这条消息立马投递，而是推迟到在当前时间点之后的某一个时间投递到 Consumer 进行消费，该消息即定时消息。

延时消息

Producer 将消息发送到消息队列 RocketMQ 服务端，但并不期望这条消息立马投递，而是延迟一定时间后才投递到 Consumer 进行消费，该消息即延时消息。

事务消息

消息队列 RocketMQ 提供类似 X/Open XA 的分布事务功能，通过消息队列 RocketMQ 的事务消息能达到分布式事务的最终一致。

顺序消息

消息队列 RocketMQ 提供的一种按照顺序进行发布和消费的消息类型, 分为全局顺序消息和分区顺序消息。

全局顺序消息

对于指定的一个 Topic，所有消息按照严格的先入先出（FIFO）的顺序进行发布和消费。

分区顺序消息

对于指定的一个 Topic，所有消息根据 sharding key 进行区块分区。同一个分区内的消息按照严格的 FIFO 顺序进行发布和消费。Sharding key 是顺序消息中用来区分不同分区的关键字段，和普通消息的 key 是完全不同的概念。

消息堆积

Producer 已经将消息发送到消息队列 RocketMQ 的服务端，但由于 Consumer 消费能力有限，未能在短时间内将所有消息正确消费掉，此时在消息队列 RocketMQ 的服务端保存着未被消费的消息，该状态即消息堆积。

消息过滤

消费者可以根据消息标签（Tag）对消息进行过滤，确保消费者最终只接收被过滤后的消息类型。消息过滤在消息队列 RocketMQ 的服务端完成。

消息轨迹

在一条消息从生产者发出到订阅者消费处理过程中，由各个相关节点的时间、地点等数据汇聚而成的完整链路信息。通过消息轨迹，您能清晰定位消息从生产者发出，经由消息队列 RocketMQ 服务端，投递给消息消费者的完整链路，方便定位排查问题。

重置消费位点

以时间轴为坐标，在消息持久化存储的时间范围内（默认 3 天），重新设置消息消费者对其订阅 Topic 的消费进度，设置完成后订阅者将接收设定时间点之后由消息生产者发送到消息队列 RocketMQ 服务端的消息。

死信队列

死信队列用于处理无法被正常消费的消息。当一条消息初次消费失败，消息队列 RocketMQ 会自动进行消息重试；达到最大重试次数后，若消费依然失败，则表明消费者在正常情况下无法正确地消费该消息，此时，消息队列 RocketMQ 不会立刻将消息丢弃，而是将其发送到该消费者对应的特殊队列中。

消息队列 RocketMQ 将这种正常情况下无法被消费的消息称为死信消息（Dead-Letter Message），将存储死信消息的特殊队列称为死信队列（Dead-Letter Queue）。

消息路由

消息路由常用于不同地域之间的消息同步，保证地域之间的数据一致性。消息队列 RocketMQ 的全球消息路由功能依托阿里云优质基础设施实现的高速通道专线，可以高效地实现国内外不同地域之间的消息同步复制。

消息队列 RocketMQ 在任何一个环境都是可扩展的，发布者必须是一个集群，消息服务器必须是一个集群，订阅者也同样。集群级别的高可用，是消息队列 RocketMQ 跟其他的消息服务器的主要区别，消息发布者（Producer）发送一条消息到消息服务器，消息服务器会随机的选择一个消费者（Consumer），只要这个消费者消费成功我们就认为是成功了。

注意：文中所提及的消息队列 RocketMQ 的服务端或者服务器包含 Name Server、Broker 等。服务端不等同于 Broker。

系统部署架构

系统部署架构如下图所示。

图中所涉及到的概念如下所述：

• Name Server: 是一个几乎无状态节点，可集群部署，在消息队列 RocketMQ 中提供命名服务，更新和发现 Broker 服务。

• Broker：分为 Master Broker 和 Slave Broker，一个 Master Broker 可以对应多个 Slave Broker，但是一个 Slave Broker 只能对应一个 Master Broker。Broker 启动后需要完成一次将自己注册至 Name Server 的操作；随后每隔 30s 定期向 Name Server 上报 Topic 路由信息。

• Producer：与 Name Server 集群中的其中一个节点（随机）建立长链接（Keep-alive），定期从 Name Server 读取 Topic 路由信息，并向提供 Topic 服务的 Master Broker 建立长链接，且定时向 Master Broker 发送心跳。

• Consumer： 与 Name Server 集群中的其中一个节点（随机）建立长连接，定期从 Name Server 拉取 Topic 路由信息，并向提供 Topic 服务的 Master Broker、Slave Broker 建立长连接，且定时向 Master Broker、Slave Broker 发送心跳。Consumer 既可以从 Master Broker 订阅消息，也可以从 Slave Broker 订阅消息，订阅规则由 Broker 配置决定。

订阅模式

消息队列 RocketMQ 的订阅模式采用的是发布/订阅模式（Pub/Sub 模式），如下图所示。

Producer 集群: 用来表示一个发送消息应用，一个 Producer 集群下包含多个 Producer 实例，可以是多台机器，也可以是一台机器的多个进程，或者一个进程的多个 Producer 对象。一个 Producer 集群可以发送多个 Topic 消息。可以想象一下，发送分布式事物消息时，如果 Producer 中途意外宕机，Broker 会主动回调 Producer 集群的任意一台机器来确认事务状态。

Consumer 集群：用来表示一个消费消息应用，一个 Consumer 集群下包含多个 Consumer 实例，可以是多台机器，也可以是多个进程，或者是一个进程的多个 Consumer 对象。一个 Consumer 集群下的多个 Consumer 以均摊方式消费消息。如果设置的是广播方式，那么这个 Consumer 集群下的每个实例都消费全量数据。

一个 Consumer 对应一个 Group ID，一个 Group ID 可以订阅多个 Topic，如图中的 Group 1 所示。Group 和 Topic 的订阅关系可以通过直接在程序中设置即可。

note:今天你是否成功取决于你昨天的态度，今天的态度决定了你明天是否成功。