持续创作，加速成长！这是我参与「掘金日新计划 · 6 月更文挑战」的第32天，点击查看活动详情

1. RocketMQ 消息模型

RocketMQ主要由 Producer、Topic、Consumer 三部分组成，其中Producer 负责生产消息，Consumer 负责消费消息，Topic是一个逻辑概念，其中的 Broker 负责存储消息。

1.1 Producer

负责生产消息，消息生产者会把业务应用系统里产生的消息发送到broker服务器。

同一类Producer的集合是 Producer Group，这类Producer发送同一类消息且发送逻辑一致，如果发送的是事务消息且原始生产者在发送之后崩溃，则Broker服务器会联系同一生产者组的其他生产者实例以提交或回溯消费。

负责消费消息，消息消费者会从 Broker 服务器拉取消息、并将其提供给应用程序。从用户应用的角度而言提供了两种消费形式：拉取式消费（Consumer 向 Broker 要）、推动式消费（Broker 主动推给 Consumer）。

同一类Consumer的集合是 Consumer Group，这类Consumer通常消费同一类消息且消费逻辑一致。消费者组使得在消息消费方面，实现负载均衡和容错的目标变得非常容易。要注意的是，消费者组的消费者实例必须订阅完全相同的Topic。

消息消费有两种形式：

表示一类消息的集合，每个 Topic 包含若干条消息，每条消息只能属于一个主题，是RocketMQ进行消息订阅的基本单位。

RocketMQ 的消费顺序有两种形式：

普通顺序消费模式下，消费者通过同一个消息队列（ Topic 分区，称作 Message Queue）收到的消息是有顺序的，不同消息队列收到的消息则可能是无顺序的。
严格顺序消息模式下，一个 Topic 中，消费者收到的所有消息均是有顺序的。

代理服务器，Topic 的物理宿主，负责存储与转发消息，代理服务器也存储消息相关的元数据，包括消费者组、消费进度偏移和主题和队列消息等。

RocketMQ 的消息体中有 Tag 标签，可以在消费端利用 Tag 标签进行过滤或者适当的消费行为。

生产者根据本地事务执行结果向服务端提交二次确认结果（Commit或是Rollback），Broker 收到确认结果后处理逻辑如下：
1. 二次确认结果为Commit：服务端将半事务消息标记为可投递，并投递给消费者。
2. 二次确认结果为Rollback：服务端不会将该消息投递给消费者，并按照如下逻辑进行回查处理。

事务消息回查步骤如下：

在断网或者是生产者应用重启的特殊情况下，上述步骤4提交的二次确认最终未到达 Broker，经过固定时间后，Broker 将对消息生产者即生产者集群中任一生产者实例发起消息回查。

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

在RocketMQ中，可以通过使用console控制台对死信队列中的消息进行重发来使得消费者实例再次进行消费。

Producer 与 NameServer集群中的其中一个节点（随机选择）建立长连接，定期从 NameServer 获取 Topic 路由信息，并向提供 Topic 服务的 Broker Master 建立长连接，且定时向 Broker 发送心跳。

Producer 只能将消息发送到 Broker master，但是 Consumer 则不一样，它同时和提供 Topic 服务的 Master 和 Slave建立长连接，既可以从 Broker Master 订阅消息，也可以从 Broker Slave 订阅消息。

每个 Broker 与 Name Server 集群中的所有节点建立长连接，定时注册 Topic 信息到所有 Name Server。