java—13 RocketMQ

一、原理

RocketMQ架构上主要分为四部分，分别为Producer、Consumer、NameServer和 BrokerServer。如下图所示:

1. NameServer

NameServer是一个非常简单的Topic路由注册中心，其角色类似Dubbo中的zookeeper， 支持Broker的动态注册与发现。 主要包括两个功能：

• ① Broker管理 NameServer接受Broker集群的注册信息并且保存下来作为路由信息的基本数据。然后 提供心跳检测机制，检查Broker是否还存活；
• ② 路由信息管理 每个NameServer将保存关于Broker集群的整个路由信息和用于客户端查询的队列信息。 然后Producer和Conumser通过NameServer就可以知道整个Broker集群的路由信息，从而进 行消息的投递和消费。

NameServer通常也采用集群的方式部署，各实例间相互不进行信息通讯。Broker是向每 一台NameServer注册自己的路由信息，所以每一个NameServer实例上面都保存一份完 整的路由信息。当某个NameServer因某种原因下线了，Broker仍然可以向其它 NameServer同步其路由信息，Producer和Consumer仍然可以动态感知Broker的路由的信 息。

2. BrokerServer

Broker主要负责消息的存储、投递和查询以及服务高可用保证，为了实现这些功能。 Broker包含了以下几个重要子模块：

• ① Remoting Module 负责处理来自Client端的请求。
• ② Client Manager 负责管理客户端(Producer/Consumer)和维护 Consumer的Topic订阅信息。
• ③ Store Service 提供方便简单的API接口处理消息存储到物理 硬盘和查询功能。
• ④ HA Service 高可用服务，提供Master Broker 和 Slave Broker之间的数据同步功能。
• ⑤ Index Service 根据特定的Message key对投递到Broker的 消息进行索引服务，以提供消息的快速查询。

3. Group、Topic、Tag之间的关系

一个班代表一个GroupID，每个班有N 个学生。  同学即是一个消费者（Consumer）， 每个同学可以选择参加多个假期活动， 如：儿童公园，水上乐园（即消费者可 以订阅多个Topic）。  儿童公园、水上乐园代表不同Topic， 儿童公园有多个游乐项目（即：Topic 有N个Tag标签）

4. 消息存储

RocketMQ消息的存储是由ConsumeQueue和CommitLog配合完成的，消息真正的物理存储文件是 CommitLog，ConsumeQueue是消息的逻辑队列，类似数据库的索引文件，存储的是指向物理存储的 地址。每个Topic下的每个MessageQueue都有一个对应的ConsumeQueue文件。

5. 消息刷盘

同步刷盘：只有在消息真正持久化至磁盘后 RocketMQ的Broker端才会真正返回给 Producer端一个成功的ACK响应。同步 刷盘对MQ消息可靠性来说是一种不错的 保障，但是性能上会有较大影响，一般 适用于金融业务应用该模式较多。

异步刷盘：能够充分利用OS的PageCache的优势， 只要消息写入PageCache即可将成功的 ACK返回给Producer端。消息刷盘采用 后台异步线程提交的方式进行，降低了 读写延迟，提高了MQ的性能和吞吐量。

6. 高可用性-主从集群

通过搭建RocketMQ集群，采用多Master搭配多Slave的方式，实现整个RocketMQ集群的高可用性的。

• ① Master节点：在broker.conf配置文件中，如果brokerId等于0，则表明这个Broker是Master。 其中，通过brokerRole，也标识这个Broker是Master还是Slave。 Master Broker支持读和写。
• ② Slave节点：如果brokerId大于0，则表明这个Broker是Slave。 Slave Broker仅支持读。

Producer端高可用：在创建Topic的时候，把Topic的多个MessageQueue创建在多个Broker组上（相同Broker名称，不同 brokerId的机器组成一个Broker组），这样当一个Broker组的Master不可用后，其他组的Master仍然可用， Producer仍然可以发送消息。 RocketMQ目前还不支持把Slave自动转成Master，如果机器资源不足，需要 把Slave转成Master，则要手动停止Slave角色的Broker，更改配置文件，用新的配置文件启动Broker。

Consumer端高可用：Consumer端默认会从Master Broker节点取读取消息，但是如果Master负载较高或者Master不可用了， 那么Consumer会自动的切换为去Slave Broker节点中读取数据。

7. 高可用性-主从复制

主从复制：在RocketMQ集群中，消息需要从Master复制到Slave上，可以通过在broker.conf里配置 brokerRole来确定复制方式。 其中，如果是主节点，则可以配置SYNC_MASTER（同步复制）或ASYNC_MASTER（异步 复制）； 如果是从节点，则配置为：SLAVE。

那么下面我们来详细介绍一下这两种复制方式：

① 同步复制 同步复制方式是等Master和Slave都写成功之后才反馈给客户端写成功状态； 在同步复制方式下，如果Master出故障， Slave上有全部的备份数据，容易恢复，但是同 步复制会增大数据写入延迟，降低系统吞吐量。

② 异步复制 异步复制方式是只要Master写成功就可以反馈给客户端写成功状态。 在异步复制方式下，系统拥有较低的延迟和较高的吞吐量，但是如果Master出了故障，有 些数据因为没有被写 入Slave，有可能会丢失；

8. 消息重试

顺序消息重试：对于顺序消息，当消费者消费消息失败后，消息队列 RocketMQ会自动不断进行消息重试（每次间隔时间为1 秒），这时，应用会出现消息消费被阻塞的情况。因此， 在使用顺序消息时，务必保证应用能够及时监控并处理 消费失败的情况，避免阻塞现象的发生。

无序消息重试：对于无序消息（普通、定时、延时、事务消息），当 消费者消费消息失败时，您可以通过设置返回状态达到 消息重试的结果。无序消息的重试只针对集群消费方式 生效；广播方式不提供失败重试特性，即消费失败后， 失败消息不再重试，继续消费新的消息。 RocketMQ默认允许每条消息最多重试16次，如果消 息重试16次后仍然失败，消息将不再投递。需要注意的 是，一条消息无论重试多少次，这些重试消息的Message ID不会改变。每次重试的间隔时间如表格所示：

9. 死信队列

当一条消息第一次消费失败，RocketMQ会自动进行消息重试。但是如果达到最大重试次 数后，若消费依然失败，则表明消费者在正常情况下无法正确地消费该消息，此时， RocketMQ不会立刻将消息丢弃，而是将其发送到该消费者对应的死信消息（Dead-Letter Message）中。

死信消息具有以下特性： 不会再被消费者正常消费。 有效期与正常消息相同，均为3天，3天后会被自动删除。因此，请在死信消息产生后的 3天内及时处理。

死信队列具有以下特性： 一个死信队列对应一个Group ID，而不是对应单个消费者实例。 如果一个Group ID未产生死信消息，RocketMQ不会为其创建相应的死信队列。 一个死信队列包含了对应Group ID产生的所有死信消息，不论该消息属于哪个Topic。