RocketMQ on 小盒子的技术分享

自顶向下学习 RocketMQ（十）：消息重投和消息重试

Tue, 18 Jan 2022 10:59:23 +0000

消息重投

“

生产者在发送消息时，同步消息失败会重投，异步消息有重试，oneway 没有任何保证。消息重投保证消息尽可能发送成功、不丢失，但可能会造成消息重复，消息重复在 RocketMQ 中是无法避免的问题。消息重复在一般情况下不会发生，当出现消息量大、网络抖动，消息重复就会是大概率事件。另外，生产者主动重发、consumer 负载变化也会导致重复消息。如下方法可以设置消息重试策略：

retryTimesWhenSendFailed: 同步发送失败重投次数，默认为 2，因此生产者会最多尝试发送 retryTimesWhenSendFailed + 1 次。不会选择上次失败的>broker，尝试向其他 broker 发送，最大程度保证消息不丢。超过重投次数，抛出异常，由客户端保证消息不丢。当出现 RemotingException、>MQClientException 和部分 MQBrokerException 时会重投。

retryTimesWhenSendAsyncFailed: 异步发送失败重试次数，异步重试不会选择其他 broker，仅在同一个 broker 上做重试，不保证消息不丢。

retryAnotherBrokerWhenNotStoreOK: 消息刷盘（主或备）超时或 slave 不可用（返回状态非 SEND_OK），是否尝试发送到其他 broker，默认 false。十分重要消息可以开启。

”

此外，只有普通消息具有发送重试机制，顺序消息是没有的。

retryTimesWhenSendFailed

同步发送失败策略

1DefaultMQProducer producer = new DefaultMQProducer("pg"); 
2producer.setNamesrvAddr("rocketmqOS:9876"); 
3// 设置同步发送失败时重试发送的次数，默认为 2 次 
4producer.setRetryTimesWhenSendFailed(3); 
5// 设置发送超时时限为 5s，默认 3s 
6producer.setSendMsgTimeout(5000);

在我们 Spring Cloud Stream + Spring Cloud Alibaba RocketMQ 的例子的配置里，我们可以这样配置：

通过源码可以看到，它的默认值是 2：

retryTimesWhenSendAsyncFailed

异步发送失败策略

1DefaultMQProducer producer = new DefaultMQProducer("pg"); 
2producer.setNamesrvAddr("rocketmqOS:9876"); 
3// 指定异步发送失败后不进行重试发送 
4producer.setRetryTimesWhenSendAsyncFailed(0);

在我们 Spring Cloud Stream + Spring Cloud Alibaba RocketMQ 的例子的配置里，我们可以这样配置：

通过源码可以看到，它的默认值也是 2：

retryAnotherBrokerWhenNotStoreOK

消息刷盘失败策略

消息刷盘超时（ Master 、 Slave ），默认是不会将消息尝试发送到其他 Broker。对于重要消息可以通过在 Broker 的配置文件设置 retryAnotherBrokerWhenNotStoreOK 属性为 true 来开启。

在我们 Spring Cloud Stream + Spring Cloud Alibaba RocketMQ 的例子的配置里，我们可以这样配置：

消息重试

“

Consumer 消费消息失败后，要提供一种重试机制，令消息再消费一次。Consumer 消费消息失败通常可以认为有以下几种情况：

由于消息本身的原因，例如反序列化失败，消息数据本身无法处理（例如话费充值，当前消息的手机号被注销，无法充值）等。这种错误通常需要跳过这条消息，再消费其它消息，而这条失败的消息即使立刻重试消费，99%也不成功，所以最好提供一种定时重试机制，即过 10 秒后再重试。

由于依赖的下游应用服务不可用，例如 db 连接不可用，外系统网络不可达等。遇到这种错误，即使跳过当前失败的消息，消费其他消息同样也会报错。这种情况建议应用 sleep 30s，再消费下一条消息，这样可以减轻 Broker 重试消息的压力。

RocketMQ 会为每个消费组都设置一个 Topic 名称为“%RETRY%+consumerGroup”的重试队列（这里需要注意的是，这个 Topic 的重试队列是针对消费组，而不是针对每个 Topic 设置的），用于暂时保存因为各种异常而导致 Consumer 端无法消费的消息。考虑到异常恢复起来需要一些时间，会为重试队列设置多个重试级别，每个重试级别都有与之对应的重新投递延时，重试次数越多投递延时就越大。RocketMQ 对于重试消息的处理是先保存至 Topic 名称为“SCHEDULE_TOPIC_XXXX”的延迟队列中，后台定时任务按照对应的时间进行 Delay 后重新保存至“%RETRY%+consumerGroup”的重试队列中。

”

消费者消费某条消息失败后，会根据消息重试机制将该消息重新投递，若达到重试次数后消息还没有成功被消费，则消息将被投入死信队列。一条消息无论重试多少次，这些重试消息的 Message ID 不会改变。

suspendCurrentQueueTimeMillis

同步消费（顺序消息）消息模式下消费失败后再次消费的时间间隔。默认值：1000 ms

在我们 Spring Cloud Stream + Spring Cloud Alibaba RocketMQ 的例子的配置里，我们可以这样配置：

顺序消息的重试是无休止的，不间断的，直至消费成功，所以，对于顺序消息的消费，务必要保证应用能够及时监控并处理消费失败的情况，避免消费被永久性阻塞。

顺序消息没有发送失败重试机制，但具有消费失败重试机制

MaxReconsumeTimes

无序消息（包括普通消息、延时消息、定时消息和事务消息）的最大重试次数可通过自定义参数 MaxReconsumeTimes 取值进行配置。默认值为 16 次，该参数取值无最大限制，建议使用默认值。

间隔时间根据重试次数阶梯变化，取值范围：1 秒~2 小时。不支持自定义配置。

若最大重试次数小于等于 16 次，则间隔时间按照无序消息重试间隔时间阶梯变化。若最大重试次数大于 16 次，则超过 16 次的间隔时间均为 2 小时。

delayLevelWhenNextConsume

异步消费消息模式下消费失败重试策略：

-1, 不重复，直接放入死信队列
0,broker 控制重试策略
0,client 控制重试策略

默认值：0.

在我们 Spring Cloud Stream + Spring Cloud Alibaba RocketMQ 的例子的配置里，我们可以这样配置：

死信队列

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

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

对于无序消息集群消费下的重试消费，默认允许每条消息最多重试 16 次，如果消息重试 16 次后仍然失败，消息将被投递至死信队列

特征

不会再被消费者正常消费
有效期与正常消息相同，均为 3 天，3 天后会被自动删除

特性

一个死信队列对应一个 Group ID，而不是对应单个消费者实例。名称为 %DLQ%consumerGroup@consumerGroup
如果一个 Group ID 未产生死信消息，则不会为其创建相应的死信队列
一个死信队列包含了对应 Group ID 产生的所有死信消息，不论该消息属于哪个 Topic

参考

自顶向下学习 RocketMQ（九）：回溯消费

Mon, 17 Jan 2022 06:52:31 +0000

定义

“

回溯消费是指 Consumer 已经消费成功的消息，由于业务上需求需要重新消费，要支持此功能，Broker 在向 Consumer 投递成功消息后，消息仍然需要保留。并且重新消费一般是按照时间维度，例如由于 Consumer 系统故障，恢复后需要重新消费 1 小时前的数据，那么 Broker 要提供一种机制，可以按照时间维度来回退消费进度。RocketMQ 支持按照时间回溯消费，时间维度精确到毫秒。

”

Demo

我们仍然是利用 Spring Cloud Stream 的编程模型 + Spring Cloud Alibaba RocketMQ 来实现。

理论

在消费时，可以设置一个字段 ConsumeFromWhere（源码位置在：org.apache.rocketmq.common.consumer.ConsumeFromWhere），从哪开始消费。可选参数，去掉 Deprecated 的，剩下的就是

1public enum ConsumeFromWhere {
2 CONSUME_FROM_LAST_OFFSET,
3 CONSUME_FROM_FIRST_OFFSET,
4 CONSUME_FROM_TIMESTAMP,
5}

CONSUME_FROM_LAST_OFFSET：从最后的偏移量开始消费
CONSUME_FROM_FIRST_OFFSET：从最小偏移量开始消费
CONSUME_FROM_TIMESTAMP：从某个时间开始消费

我们需要设置从某个时间开始消费，即配置 CONSUME_FROM_TIMESTAMP 并设置好具体的时间点。

实现

首先还是看一下配置文件

 1server:
 2 port: 8080
 3 servlet:
 4 context-path: /mq-example
 5
 6spring:
 7 
 8 application:
 9 name: mq-example
10 cloud:
11 stream:
12 bindings:
13
14 input-backtracking:
15 content-type: application/json
16 destination: test-topic3
17 group: backtracking-consumer-group
18
19 # 定义 name 为 output 的 binding 生产
20 output-order:
21 content-type: application/json
22 destination: test-topic3
23
24 rocketmq:
25 # RocketMQ Binder 配置项，对应 RocketMQBinderConfigurationProperties 类
26 binder:
27 # 配置 rocketmq 的 nameserver 地址
28 name-server: 127.0.0.1:9876
29 group: rocketmq-group
30 bindings:
31 output-order:
32 # RocketMQ Producer 配置项，对应 RocketMQProducerProperties 类
33 producer:
34 #group: producer-group # 生产者分组
35 sync: true # 是否同步发送消息，默认为 false 异步。
36 input-backtracking: # 回溯消息配置
37 # com.alibaba.cloud.stream.binder.rocketmq.properties.RocketMQConsumerProperties
38 consumer:
39 consumeFromWhere: CONSUME_FROM_TIMESTAMP
40 consumeTimestamp: 20220117110148
41 enabled: true # 是否开启消费，默认为 true
42 broadcasting: false # 是否使用广播消费，默认为 false 使用集群消费

这里我们仍然用之前的 ouput-order 作为生产者，生产消息。

消息者配置上主要注意 input-backtracking 节点中的属性配置：

consumeFromWhere 即上文提到的从哪儿开始消费，这里我们指定时间消费
consumeTimestamp 即指定的时间点

程序入口：

1@SpringBootApplication
2@EnableBinding({ MySource.class})
3public class MqBootstrapApplication {
4 public static void main(String[] args) {
5 SpringApplication.run(MqBootstrapApplication.class);
6 }
7
8}

要加上 @EnableBinding

MySource:

1public interface MySource {
2
3 @Output("output-order")
4 MessageChannel output4Order();
5
6 @Input("input-backtracking")
7 MessageChannel inputBackTracking();
8
9}

controller 生产消息：

 1@GetMapping("/produce")
 2 public void produceMsg() {
 3
 4 Map<String, Object> headers = Maps.newHashMapWithExpectedSize(16);
 5 headers.put(MessageConst.PROPERTY_DELAY_TIME_LEVEL, 2);
 6 headers.put(MessageConst.PROPERTY_TAGS, "test03");
 7
 8 Order order = Order.builder().id(1L).desc("test").build();
 9 Message message = MessageBuilder.createMessage(order, new MessageHeaders(headers));
10 mySource.output4Order().send(message);
11
12 }

ReceiveService 消费消息：

 1
 2@Service
 3@Log4j2
 4public class ReceiveService {
 5
 6 @StreamListener("input-backtracking")
 7 public void receiveBackTrackingInput(String receiveMsg, GenericMessage message, @Headers Map headers) {
 8
 9 log.info("接收到回溯消息：{}", receiveMsg);
10
11 }
12
13}

测试

可以先调用 controller 生产消息，或者不用 Demo 中的生产者生产消息，找一个之前发过消息的 topic , 看一下它的消息轨迹，找到存储时间

如果你用之前发过消息的 topic 记得修改配置文件中的 topic名称：

确认找到的这条消息已经被消费过（因为要测回溯，至少是二次消费），将 consumeTimestamp 的时间配置在存储时间之后。

这时启动项目，观察 ReceiveService 的输出：

1 接收到回溯消息：{"id":1,"desc":"test"}

证明消息回溯消费成功。

参考

自顶向下学习 RocketMQ（八）：事务消息原理分析

Thu, 13 Jan 2022 10:19:03 +0000

RocketMQ 5.0

在了解事务消息原理之前，先说点版本相关的事情，我们的 demo 和原码分析是以 4.9 版本为基础的，而 RocketMQ 的最新版本已经是 5.0 了，看一下 RocketMQ 5.0 的最新进展，从里程碑上来看目前是在 alpha 阶段。

功能上，看下官宣：

不知道以后阿里云上商业版本和开源版本能不能对齐，但从架构上功能上确实比 5.0 之前的有很大调整。至于在云原生领域是否和 apache pulsar (https://pulsar.apache.org/) 呈 PK 之势，就让我们拭目以待吧。

事务流程

我们再回顾一下事务流程

事务消息发送步骤如下：

生产者将半事务消息发送至消息队列 RocketMQ 版服务端。
消息队列 RocketMQ 版服务端将消息持久化成功之后，向生产者返回 Ack 确认消息已经发送成功，此时消息为半事务消息。
生产者开始执行本地事务逻辑。
生产者根据本地事务执行结果向服务端提交二次确认结果（Commit 或是 Rollback），服务端收到确认结果后处理逻辑如下：

二次确认结果为 Commit：服务端将半事务消息标记为可投递，并投递给消费者。
二次确认结果为 Rollback：服务端不会将该消息投递给消费者，并按照如下逻辑进行回查处理。

事务消息回查步骤如下：

在断网或者是生产者应用重启的特殊情况下，上述步骤 4 提交的二次确认最终未到达服务端，经过固定时间后，服务端将对消息生产者即生产者集群中任一生产者实例发起消息回查。
生产者收到消息回查后，需要检查对应消息的本地事务执行的最终结果。
生产者根据检查得到的本地事务的最终状态再次提交二次确认，服务端仍按照步骤 4 对半事务消息进行处理。

源码流程

有关源码的走读流程，这里有一篇文章该写的都写了，写的挺好的，我就不赘述了：

https://juejin.cn/post/7017973903561605151#heading-9

参考

自顶向下学习 RocketMQ（七）：事务消息

Mon, 10 Jan 2022 23:50:00 +0000

定义

“

RocketMQ 事务消息（Transactional Message）是指应用本地事务和发送消息操作可以被定义到全局事务中，要么同时成功，要么同时失败。RocketMQ 的事务消息提供类似 X/Open XA 的分布事务功能，通过事务消息能达到分布式事务的最终一致。

”

Demo

下面的例子，还是以 spring cloud stream 编程模型为基础，结合 spring cloud alibaba RocketMQ 的实现，演示了如何使用事务消息。

流程

事务消息交互流程如下图所示：

事务消息发送步骤如下：

生产者将半事务消息发送至消息队列 RocketMQ 版服务端。
消息队列 RocketMQ 版服务端将消息持久化成功之后，向生产者返回 Ack 确认消息已经发送成功，此时消息为半事务消息。
生产者开始执行本地事务逻辑。
生产者根据本地事务执行结果向服务端提交二次确认结果（Commit 或是 Rollback），服务端收到确认结果后处理逻辑如下：

二次确认结果为 Commit：服务端将半事务消息标记为可投递，并投递给消费者。
二次确认结果为 Rollback：服务端不会将该消息投递给消费者，并按照如下逻辑进行回查处理。

事务消息回查步骤如下：

在断网或者是生产者应用重启的特殊情况下，上述步骤 4 提交的二次确认最终未到达服务端，经过固定时间后，服务端将对消息生产者即生产者集群中任一生产者实例发起消息回查。
生产者收到消息回查后，需要检查对应消息的本地事务执行的最终结果。
生产者根据检查得到的本地事务的最终状态再次提交二次确认，服务端仍按照步骤 4 对半事务消息进行处理。

配置

和之前一样，我将生产者消息者配置在一起了，先来看一下配置文件：

 1spring:
 2 application:
 3 name: mq-example
 4 cloud:
 5 stream:
 6 bindings:
 7
 8 input-transaction:
 9 content-type: application/json
10 destination: TransactionTopic
11 group: transaction-consumer-group
12 
13 output-transaction:
14 content-type: application/json
15 destination: TransactionTopic
16
17 rocketmq:
18 # RocketMQ Binder 配置项，对应 RocketMQBinderConfigurationProperties 类
19 binder:
20 # 配置 rocketmq 的 nameserver 地址
21 name-server: 127.0.0.1:9876
22 group: rocketmq-group
23 bindings:
24 output-transaction:
25 # 对应 RocketMQProducerProperties 类
26 producer:
27 producerType: Trans
28 group: transaction-producer-group # 生产者分组
29 transactionListener: myTransactionListener
30

这里需要注意生产者类型为：Trans 即，事务消息。

还配置了相应的生产者组和消费者组，这里回顾一下这两个概念

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

生产者组：同一类 Consumer 的集合，这类 Consumer 通常消费同一类消息且消费逻辑一致。消费者组使得在消息消费方面，实现负载均衡和容错的目标变得非常容易。要注意的是，消费者组的消费者实例必须订阅完全相同的 Topic。RocketMQ 支持两种消息模式：集群消费（Clustering）和广播消费（Broadcasting）。

实现

transactionListener 为我们自定义的事务监听器，具体代码见下文：

 1@Component("myTransactionListener")
 2public class TransactionListenerImpl implements TransactionListener {
 3
 4 @Override
 5 public LocalTransactionState executeLocalTransaction(Message msg, Object arg) {
 6 Object num = msg.getProperty("test");
 7
 8 if ("1".equals(num)) {
 9 System.out.println("executer: " + new String(msg.getBody()) + " unknown");
10 return LocalTransactionState.UNKNOW;
11 } else if ("2".equals(num)) {
12 System.out.println("executer: " + new String(msg.getBody()) + " rollback");
13 return LocalTransactionState.ROLLBACK_MESSAGE;
14 }
15 System.out.println("executer: " + new String(msg.getBody()) + " commit");
16 return LocalTransactionState.COMMIT_MESSAGE;
17 }
18
19 @Override
20 public LocalTransactionState checkLocalTransaction(MessageExt msg) {
21 System.out.println("check: " + new String(msg.getBody()));
22 return LocalTransactionState.COMMIT_MESSAGE;
23 }
24
25}

以上代码是参考官方的 Demo, 可以看到根据 num 的不同，返回不同的事务状态

如果 num 为 1，则返回 UNKNOW，表示本地事务状态未知，需要定期回查事务状态，则会执行 checkLocalTransaction 方法。
如果 num 为 2，则返回 ROLLBACK_MESSAGE，表示本地事务状态为回滚，则 broker 会回滚之前的提交的事务消息，即不投递消息。
如果 num 为 3，则返回 COMMIT_MESSAGE，表示本地事务状态为提交，则 broker 会投递消息。

发送消息跟之前的代码类似：

 1 @GetMapping("/send_transaction")
 2 public void sendTransaction() {
 3
 4 String msg = "这是一条事务消息";
 5 Integer num = 2;
 6
 7 MessageBuilder builder = MessageBuilder.withPayload(msg)
 8 .setHeader(MessageHeaders.CONTENT_TYPE, MimeTypeUtils.APPLICATION_JSON);
 9 builder.setHeader("test", String.valueOf(num));
10 builder.setHeader(RocketMQConst.USER_TRANSACTIONAL_ARGS, "binder");
11 Message message = builder.build();
12 mySource.outputTransaction().send(message);
13 }

为了保证可靠消息最终一致性，需要有一个数据库表记录事务状态，

事务开始的时候先将 UNKNOW 状态存起来，当事务异常时，返回 ROLLBACK_MESSAGE 状态，并且在数据库表中记录此状态。当事务提交成功时，将状态修改为 COMMIT_MESSAGE。

有了事务消息表，checkLocalTransaction 方法就可以依据此表进行事务状态的查询。

当然，如果按上图所示，一个完整的分布式事务跨越 A、B 两个系统，如果 B 系统事务失败回滚时，考虑 A 系统的事务是否需要回滚，如需要，还需要 A 系统提供回滚接口，供 B 系统调用。

参考

自顶向下学习 RocketMQ（六）：定时消息

Mon, 10 Jan 2022 01:23:47 +0000

定义和原理

定时消息（延迟队列）是指消息发送到 broker 后，不会立即被消费，等待特定时间投递给真正的 topic。

broker 有配置项 messageDelayLevel，默认值为 1s 5s 10s 30s 1m 2m 3m 4m 5m 6m 7m 8m 9m 10m 20m 30m 1h 2h 18 个 level , 可以配置自定义 messageDelayLevel。

注意，messageDelayLevel 是 broker 的属性，不属于某个 topic。发消息时，设置 delayLevel 等级即可：msg.setDelayLevel(level)。level 有以下三种情况：

level == 0，消息为非延迟消息
1<=level<=maxLevel，消息延迟特定时间，例如 level==1，延迟 1s
level > maxLevel，则 level== maxLevel，例如 level==20，延迟 2h

定时消息会暂存在名为 SCHEDULE_TOPIC_XXXX 的 topic 中，并根据 delayTimeLevel 存入特定的 queue，queueId = delayTimeLevel – 1，即一个 queue 只存相同延迟的消息，保证具有相同发送延迟的消息能够顺序消费。broker 会调度地消费 SCHEDULE_TOPIC_XXXX，将消息写入真实的 topic。

RocketMQ 暂时不支持任意时间的定时

简化一个实现原理方案示意图：

分为两个部分：

消息的写入
消息的 Schedule

消息写入中：

在写入 CommitLog 之前，如果是延迟消息，替换掉消息的 Topic 和 queueId（被替换为延迟消息特定的 Topic，queueId 则为延迟级别对应的 id)
消息写入 CommitLog 之后，提交 dispatchRequest 到 DispatchService
因为在第①步中 Topic 和 QueueId 被替换了，所以写入的 ConsumeQueue 实际上非真正消息应该所属的 ConsumeQueue，而是写入到 ScheduledConsumeQueue 中（这个特定的 Queue 存放不会被消费）

Schedule 过程中：

给每个 Level 设置定时器，从 ScheduledConsumeQueue 中读取信息
如果 ScheduledConsumeQueue 中的元素已近到时，那么从 CommitLog 中读取消息内容，恢复成正常的消息内容写入 CommitLog
写入 CommitLog 后提交 dispatchRequest 给 DispatchService
因为在写入 CommitLog 前已经恢复了 Topic 等属性，所以此时 DispatchService 会将消息投递到正确的 ConsumeQueue 中

Demo

配置

由于 spring cloud alibaba 低版本的 rocketmq 定时消息功能有问题，不能实现，所以必须换高版本的，下面是我使用的版本信息：

1<spring.boot.version>2.3.12.RELEASE</spring.boot.version>
2<spring.cloud.version>Hoxton.SR12</spring.cloud.version>
3<spring.cloud.alibaba.version>2.2.7.RELEASE</spring.cloud.alibaba.version>

引入的是 starter

1 <dependency>
2 <groupId>com.alibaba.cloud</groupId>
3 <artifactId>spring-cloud-starter-stream-rocketmq</artifactId>
4</dependency>

分享一下我的配置文件：

 1spring:
 2
 3 application:
 4 name: mq-example
 5 cloud:
 6 stream:
 7 bindings:
 8 # 定义 name 为 input 的 binding 消费
 9 input:
10 content-type: application/json
11 destination: test-topic3
12 group: consumer-group
13 # 定义 name 为 output 的 binding 生产
14 output-order:
15 content-type: application/json
16 destination: test-topic3
17 # Producer 配置项，对应 ProducerProperties 类
18 #producer:
19 # partition-key-expression: payload['id'] # 分区 key 表达式。该表达式基于 Spring EL，从消息中获得分区 key。
20 #partitionCount: 3 # 分区数量
21 rocketmq:
22 # RocketMQ Binder 配置项，对应 RocketMQBinderConfigurationProperties 类
23 binder:
24 # 配置 rocketmq 的 nameserver 地址
25 name-server: 127.0.0.1:9876
26 group: rocketmq-group
27 bindings:
28 output-order:
29 # RocketMQ Producer 配置项，对应 RocketMQProducerProperties 类
30 producer:
31 #group: producer-group # 生产者分组
32 sync: true # 是否同步发送消息，默认为 false 异步。
33 input:
34 # RocketMQ Consumer 配置项，对应 RocketMQConsumerProperties 类
35 consumer:
36 #group: consumer-group # 消费者分组
37 enabled: true # 是否开启消费，默认为 true
38 broadcasting: false # 是否使用广播消费，默认为 false 使用集群消费
39 orderly: false # 是否顺序消费，默认为 false 并发消费。

这里注意红框部分在低版本有说要改成 true 才可以发送定时消息，我在高版本测试不用，true 和 false 都可以。

发送消息

消息发送部分几乎和之前一样，只是多加一了个 header PROPERTY_DELAY_TIME_LEVEL, 这里我写的是 2，即延迟 5 秒。

1 Map<String, Object> headers = Maps.newHashMapWithExpectedSize(16);
2 headers.put(MessageConst.PROPERTY_DELAY_TIME_LEVEL, 2);
3 headers.put(MessageConst.PROPERTY_TAGS, "test03");
4
5 Order order = Order.builder().id(1L).desc("test").build();
6 Message message = MessageBuilder.createMessage(order, new MessageHeaders(headers));
7 mySource.output4Order().send(message);

接收消息

接收和之前没什么区别

 1@Service
 2public class ReceiveService {
 3
 4 /**
 5 * 订阅消息
 6 *
 7 * @param receiveMsg
 8 */
 9 @StreamListener("input")
10 public void receiveInput1(String receiveMsg, GenericMessage message, @Headers Map headers) {
11
12 System.out.println(message.toString());
13 System.out.println("线程 ID: " + Thread.currentThread().getId() + " 接受到消息 input receive: " + receiveMsg);
14 }

效果

118:00:16.673 [http-nio-8080-exec-1] INFO the message has sent, ......
218:00:21.685 [ConsumeMessageThread_1] INFO 接收到消息：{"id":1,"desc":"test"}

可以看到发送到接收，相距 5 秒。

参考

自顶向下学习 RocketMQ（五）：顺序消息原理

Wed, 05 Jan 2022 09:26:40 +0000

回顾

上文中我们对 RocketMQ 的 顺序消息 进行了 spring cloud 版本的演示，这里再回顾一下：

顺序消息分为 分区顺序消息 和 全局顺序消息。

全局顺序消息其实是分区顺序消息的一种特殊情况，即如果只有一个分区且同一时间只有一个消费者线程进行消费，那么就可以看作是全局顺序消息。

在 RocketMQ 创建 topic 时默认队列（分区）数量是：8 ，是针对所有 topic 的

如果要单独设置一个 topic 的队列（分区）数量，在 spring cloud alibaba 中可以这样配置：

 1spring:
 2 
 3 application:
 4 name: mq-example
 5 cloud:
 6 stream:
 7 bindings:
 8 # 定义 name 为 input 的 binding 消费
 9 input:
10 content-type: application/json
11 destination: test-topic3
12 group: consumer-group
13 # 定义 name 为 output 的 binding 生产
14 output-order:
15 content-type: application/json
16 destination: test-topic3
17 # Producer 配置项，对应 ProducerProperties 类
18 producer:
19 partitionCount: 1 # 分区数量

注意这里 partitionCount，如将该值设置为 1，则 broker 会将消息发送到同一个分区中。

原理

本文我们重点了解一下，RocketMQ 的顺序消息的实现原理。

在 MQ 的模型中，顺序需要由 3 个阶段去保障：

消息被发送时保持顺序
消息被存储时保持和发送的顺序一致
消息被消费时保持和存储的顺序一致

RocketMQ 要想实现顺序消息，核心就是 Producer 同步发送，确保一组顺序消息被发送到同一个分区队列，然后 Consumer 确保同一个队列只被一个线程消费

发送有序

这里我们串一下代码，看一下 producer 发送消息的时候是怎么实现顺序发送的：

 1private SendResult sendDefaultImpl(Message msg, CommunicationMode communicationMode, SendCallback sendCallback, long timeout) throws MQClientException, RemotingException, MQBrokerException, InterruptedException {
 2 this.makeSureStateOK();
 3 Validators.checkMessage(msg, this.defaultMQProducer);
 4 long invokeID = this.random.nextLong();
 5 long beginTimestampFirst = System.currentTimeMillis();
 6 long beginTimestampPrev = beginTimestampFirst;
 7 TopicPublishInfo topicPublishInfo = this.tryToFindTopicPublishInfo(msg.getTopic());
 8 if (topicPublishInfo != null && topicPublishInfo.ok()) {
 9 boolean callTimeout = false;
 10 MessageQueue mq = null;
 11 Exception exception = null;
 12 SendResult sendResult = null;
 13 int timesTotal = communicationMode == CommunicationMode.SYNC ? 1 + this.defaultMQProducer.getRetryTimesWhenSendFailed() : 1;
 14 int times = 0;
 15 String[] brokersSent = new String[timesTotal];
 16
 17 while(true) {
 18 label122: {
 19 String info;
 20 if (times < timesTotal) {
 21 info = null == mq ? null : mq.getBrokerName();
 22 MessageQueue mqSelected = this.selectOneMessageQueue(topicPublishInfo, info);
 23 if (mqSelected != null) {
 24 mq = mqSelected;
 25 brokersSent[times] = mqSelected.getBrokerName();
 26
 27 long endTimestamp;
 28 try {
 29 beginTimestampPrev = System.currentTimeMillis();
 30 long costTime = beginTimestampPrev - beginTimestampFirst;
 31 if (timeout >= costTime) {
 32 sendResult = this.sendKernelImpl(msg, mq, communicationMode, sendCallback, topicPublishInfo, timeout - costTime);
 33 endTimestamp = System.currentTimeMillis();
 34 this.updateFaultItem(mq.getBrokerName(), endTimestamp - beginTimestampPrev, false);
 35 switch(communicationMode) {
 36 case ASYNC:
 37 return null;
 38 case ONEWAY:
 39 return null;
 40 case SYNC:
 41 if (sendResult.getSendStatus() == SendStatus.SEND_OK || !this.defaultMQProducer.isRetryAnotherBrokerWhenNotStoreOK()) {
 42 return sendResult;
 43 }
 44 default:
 45 break label122;
 46 }
 47 }
 48
 49 callTimeout = true;
 50 } catch (RemotingException var26) {
 51 endTimestamp = System.currentTimeMillis();
 52 this.updateFaultItem(mqSelected.getBrokerName(), endTimestamp - beginTimestampPrev, true);
 53 this.log.warn(String.format("sendKernelImpl exception, resend at once, InvokeID: %s, RT: %sms, Broker: %s", invokeID, endTimestamp - beginTimestampPrev, mqSelected), var26);
 54 this.log.warn(msg.toString());
 55 exception = var26;
 56 break label122;
 57 } catch (MQClientException var27) {
 58 endTimestamp = System.currentTimeMillis();
 59 this.updateFaultItem(mqSelected.getBrokerName(), endTimestamp - beginTimestampPrev, true);
 60 this.log.warn(String.format("sendKernelImpl exception, resend at once, InvokeID: %s, RT: %sms, Broker: %s", invokeID, endTimestamp - beginTimestampPrev, mqSelected), var27);
 61 this.log.warn(msg.toString());
 62 exception = var27;
 63 break label122;
 64 } catch (MQBrokerException var28) {
 65 endTimestamp = System.currentTimeMillis();
 66 this.updateFaultItem(mqSelected.getBrokerName(), endTimestamp - beginTimestampPrev, true);
 67 this.log.warn(String.format("sendKernelImpl exception, resend at once, InvokeID: %s, RT: %sms, Broker: %s", invokeID, endTimestamp - beginTimestampPrev, mqSelected), var28);
 68 this.log.warn(msg.toString());
 69 exception = var28;
 70 switch(var28.getResponseCode()) {
 71 case 1:
 72 case 14:
 73 case 16:
 74 case 17:
 75 case 204:
 76 case 205:
 77 break label122;
 78 default:
 79 if (sendResult != null) {
 80 return sendResult;
 81 }
 82
 83 throw var28;
 84 }
 85 } catch (InterruptedException var29) {
 86 endTimestamp = System.currentTimeMillis();
 87 this.updateFaultItem(mqSelected.getBrokerName(), endTimestamp - beginTimestampPrev, false);
 88 this.log.warn(String.format("sendKernelImpl exception, throw exception, InvokeID: %s, RT: %sms, Broker: %s", invokeID, endTimestamp - beginTimestampPrev, mqSelected), var29);
 89 this.log.warn(msg.toString());
 90 this.log.warn("sendKernelImpl exception", var29);
 91 this.log.warn(msg.toString());
 92 throw var29;
 93 }
 94 }
 95 }
 96
 97 if (sendResult != null) {
 98 return sendResult;
 99 }
100
101 info = String.format("Send [%d] times, still failed, cost [%d]ms, Topic: %s, BrokersSent: %s", times, System.currentTimeMillis() - beginTimestampFirst, msg.getTopic(), Arrays.toString(brokersSent));
102 info = info + FAQUrl.suggestTodo("http://rocketmq.apache.org/docs/faq/");
103 MQClientException mqClientException = new MQClientException(info, (Throwable)exception);
104 if (callTimeout) {
105 throw new RemotingTooMuchRequestException("sendDefaultImpl call timeout");
106 }
107
108 if (exception instanceof MQBrokerException) {
109 mqClientException.setResponseCode(((MQBrokerException)exception).getResponseCode());
110 } else if (exception instanceof RemotingConnectException) {
111 mqClientException.setResponseCode(10001);
112 } else if (exception instanceof RemotingTimeoutException) {
113 mqClientException.setResponseCode(10002);
114 } else if (exception instanceof MQClientException) {
115 mqClientException.setResponseCode(10003);
116 }
117
118 throw mqClientException;
119 }
120
121 ++times;
122 }
123 } else {
124 List<String> nsList = this.getmQClientFactory().getMQClientAPIImpl().getNameServerAddressList();
125 if (null != nsList && !nsList.isEmpty()) {
126 throw (new MQClientException("No route info of this topic, " + msg.getTopic() + FAQUrl.suggestTodo("http://rocketmq.apache.org/docs/faq/"), (Throwable)null)).setResponseCode(10005);
127 } else {
128 throw (new MQClientException("No name server address, please set it." + FAQUrl.suggestTodo("http://rocketmq.apache.org/docs/faq/"), (Throwable)null)).setResponseCode(10004);
129 }
130 }
131 }

上面是消息发送的代码，下面梳理下主要流程：

消息发送时，先根据 Topic 从 Broker 拉取 TopicPublishInfo 信息，它里面包含了 Topic 下所有的 MessageQueue。

 1 TopicPublishInfo topicPublishInfo = this.tryToFindTopicPublishInfo(msg.getTopic());
 2
 3 private TopicPublishInfo tryToFindTopicPublishInfo(String topic) {
 4 TopicPublishInfo topicPublishInfo = (TopicPublishInfo)this.topicPublishInfoTable.get(topic);
 5 if (null == topicPublishInfo || !topicPublishInfo.ok()) {
 6 this.topicPublishInfoTable.putIfAbsent(topic, new TopicPublishInfo());
 7 this.mQClientFactory.updateTopicRouteInfoFromNameServer(topic);
 8 topicPublishInfo = (TopicPublishInfo)this.topicPublishInfoTable.get(topic);
 9 }
10
11 if (!topicPublishInfo.isHaveTopicRouterInfo() && !topicPublishInfo.ok()) {
12 this.mQClientFactory.updateTopicRouteInfoFromNameServer(topic, true, this.defaultMQProducer);
13 topicPublishInfo = (TopicPublishInfo)this.topicPublishInfoTable.get(topic);
14 return topicPublishInfo;
15 } else {
16 return topicPublishInfo;
17 }
18 }
19
20public class TopicPublishInfo {
21 private boolean orderTopic = false;
22 private boolean haveTopicRouterInfo = false;
23 private List<MessageQueue> messageQueueList = new ArrayList();
24 private volatile ThreadLocalIndex sendWhichQueue = new ThreadLocalIndex();
25 private TopicRouteData topicRouteData;
26
27 public TopicPublishInfo() {
28 }
29 ...

选取一个目标队列：

1 MessageQueue mqSelected = this.selectOneMessageQueue(topicPublishInfo, info);

接着调用核心发送方法，将消息发送到 broker

1sendResult = this.sendKernelImpl(msg, mq, communicationMode, sendCallback, topicPublishInfo, timeout - costTime);

必须使用同步发送，异步/单向发送都无法保证消息被有序写入队列

sendKernelImpl 方法中有同/异步的判断，这里应该是走的 case SYNC

 1case ASYNC:
 2 Message tmpMessage = msg;
 3 if (msgBodyCompressed) {
 4 tmpMessage = MessageAccessor.cloneMessage(msg);
 5 msg.setBody(prevBody);
 6 }
 7
 8 long costTimeAsync = System.currentTimeMillis() - beginStartTime;
 9 if (timeout < costTimeAsync) {
10 throw new RemotingTooMuchRequestException("sendKernelImpl call timeout");
11 }
12
13 sendResult = this.mQClientFactory.getMQClientAPIImpl().sendMessage(brokerAddr, mq.getBrokerName(), tmpMessage, requestHeader, timeout - costTimeAsync, communicationMode, sendCallback, topicPublishInfo, this.mQClientFactory, this.defaultMQProducer.getRetryTimesWhenSendAsyncFailed(), context, this);
14 break;
15case ONEWAY:
16case SYNC:
17 long costTimeSync = System.currentTimeMillis() - beginStartTime;
18 if (timeout < costTimeSync) {
19 throw new RemotingTooMuchRequestException("sendKernelImpl call timeout");
20 }
21
22 sendResult = this.mQClientFactory.getMQClientAPIImpl().sendMessage(brokerAddr, mq.getBrokerName(), msg, requestHeader, timeout - costTimeSync, communicationMode, context, this);
23 break;
24default:
25 assert false;

Producer 保证发送有序，只要保证相同 ShardingKey 的消息发送到同一队列即可，以 spring cloud stream 的实现为例，可以查看 PartitionHandler 类中的 determinePartition 方法

 1 public int determinePartition(Message<?> message) {
 2 Object key = this.extractKey(message);
 3 int partition;
 4 if (this.producerProperties.getPartitionSelectorExpression() != null) {
 5 partition = (Integer)this.producerProperties.getPartitionSelectorExpression().getValue(this.evaluationContext, key, Integer.class);
 6 } else {
 7 partition = this.partitionSelectorStrategy.selectPartition(key, this.partitionCount);
 8 }
 9
10 return Math.abs(partition % this.partitionCount);
11 }

可以看到 partition 的值如果之前配置了分区 key 表达式如：

1 producer:
2 partition-key-expression: payload['id']

则值是表达式的值，如没有配置，则走默认策略，默认策略的实现取的是消息的 hash:

 1private static class DefaultPartitionSelector implements PartitionSelectorStrategy {
 2 private DefaultPartitionSelector() {
 3 }
 4
 5 public int selectPartition(Object key, int partitionCount) {
 6 int hashCode = key.hashCode();
 7 if (hashCode == -2147483648) {
 8 hashCode = 0;
 9 }
10
11 return Math.abs(hashCode);
12 }
13 }

最后队列的选择是利用 partition 和队列（分区）总数取模后得到的结果。这样就可以保证相同 ShardingKey 的消息发送到同一队列了。

整体的流程如下图：

消息发送后，由于队列本身的 FIFO 特性，它保存到 broker 端也是有序的。

消费有序

Consumer 默认是多线程并发消费同一个 MessageQueue 的，即使消息是顺序到达的，也不能保证消息顺序消费。

那么 RocketMQ 如何保证消息顺序消费呢？

与 producer 一样，我们按照 consumer 的流程串一下代码

consumer 启动时，在 MQClientInstance 类的 start 方法中进行了重平衡操作：

 1public void start() throws MQClientException {
 2
 3 synchronized (this) {
 4 switch (this.serviceState) {
 5 case CREATE_JUST:
 6 this.serviceState = ServiceState.START_FAILED;
 7 // If not specified,looking address from name server
 8 if (null == this.clientConfig.getNamesrvAddr()) {
 9 this.mQClientAPIImpl.fetchNameServerAddr();
10 }
11 // Start request-response channel
12 this.mQClientAPIImpl.start();
13 // Start various schedule tasks
14 this.startScheduledTask();
15 // Start pull service
16 this.pullMessageService.start();
17 // Start rebalance service
18 this.rebalanceService.start();
19 // Start push service
20 this.defaultMQProducer.getDefaultMQProducerImpl().start(false);
21 log.info("the client factory [{}] start OK", this.clientId);
22 this.serviceState = ServiceState.RUNNING;
23 break;
24 case START_FAILED:
25 throw new MQClientException("The Factory object[" + this.getClientId() + "] has been created before, and failed.", null);
26 default:
27 break;
28 }
29 }
30 }

就是这一行 rebalanceService.start() ，它的目的是给自己分配 MessageQueue。要保证一个队列被一个消费者消费，那么消费者在进行消息拉取消费时就必须向 mq 服务器申请队列锁。如果申请到琐，则拉取消息，否则放弃消息拉取，等到下一个队列负载周期 (20s) 再试。

申请锁可以参考 RebalanceImpl类 updateProcessQueueTableInRebalance 和 lock 方法中的代码：

 1 //如果是顺序消息，需要向 Broker 申请锁队列，加锁成功才开始消费。
 2for (MessageQueue mq : mqSet) {
 3 if (!this.processQueueTable.containsKey(mq)) {
 4 if (isOrder && !this.lock(mq)) {
 5 log.warn("doRebalance, {}, add a new mq failed, {}, because lock failed", consumerGroup, mq);
 6 continue;
 7 }
 8
 9 this.removeDirtyOffset(mq);
10 ProcessQueue pq = new ProcessQueue();
11
12public boolean lock(final MessageQueue mq) {
13 // 查找 Broker Master 主机地址
14 FindBrokerResult findBrokerResult = this.mQClientFactory.findBrokerAddressInSubscribe(mq.getBrokerName(), MixAll.MASTER_ID, true);
15 if (findBrokerResult != null) {
16 // 构建请求体
17 LockBatchRequestBody requestBody = new LockBatchRequestBody();
18 requestBody.setConsumerGroup(this.consumerGroup);// 消费组
19 requestBody.setClientId(this.mQClientFactory.getClientId());// 客户端实例 ID
20 requestBody.getMqSet().add(mq);// 申请锁哪些队列
21
22 try {
23 // 发送请求，Broker 返回锁住的队列集合
24 Set<MessageQueue> lockedMq =
25 this.mQClientFactory.getMQClientAPIImpl().lockBatchMQ(findBrokerResult.getBrokerAddr(), requestBody, 1000);
26 for (MessageQueue mmqq : lockedMq) {
27 ProcessQueue processQueue = this.processQueueTable.get(mmqq);
28 if (processQueue != null) {
29 processQueue.setLocked(true);
30 processQueue.setLastLockTimestamp(System.currentTimeMillis());
31 }
32 }
33 // 目标队列在里面，就说明加锁成功了
34 boolean lockOK = lockedMq.contains(mq);
35 log.info("the message queue lock {}, {} {}",
36 lockOK ? "OK" : "Failed",
37 this.consumerGroup,
38 mq);
39 return lockOK;
40 } catch (Exception e) {
41 log.error("lockBatchMQ exception, " + mq, e);
42 }
43 }
44 return false;
45}

这个锁是 Broker 维护的全局锁。

一旦加锁成功，就会开始构建 PullRequest 对象开始拉取消息，消息拉取部分的代码实现在 PullMessageService 中，拉取成功后，在 PullCallback 里会将拉取到的消息填充到 ProcessQueue，然后提交消费请求，让 ConsumeMessageOrderlyService 开始消费消息。

消费消息时，先获取 MessageQueue 的锁对象，然后通过 synchronized 关键字保证只有一个线程消费

对于顺序消息，当消费者消费消息失败后，消息队列 RocketMQ 会自动不断地进行消息重试（每次间隔时间为 1 秒），重试最大值是 Integer.MAX_VALUE

 1case SUSPEND_CURRENT_QUEUE_A_MOMENT:
 2 this.getConsumerStatsManager().incConsumeFailedTPS(consumerGroup, consumeRequest.getMessageQueue().getTopic(), msgs.size());
 3 // 校验最大重试次数，默认 Integer.MAX_VALUE
 4 if (checkReconsumeTimes(msgs)) {
 5 // 标记消息等待重新消费
 6 consumeRequest.getProcessQueue().makeMessageToConsumeAgain(msgs);
 7 // 提交消费请求，稍后重试
 8 this.submitConsumeRequestLater(
 9 consumeRequest.getProcessQueue(),
10 consumeRequest.getMessageQueue(),
11 context.getSuspendCurrentQueueTimeMillis());
12 continueConsume = false;
13 } else {
14 commitOffset = consumeRequest.getProcessQueue().commit();
15 }
16 break;

最后补充一点，在消费的过程中，会对处理队列 (ProccessQueue) 进行加锁，保证处理中的消息消费完成，发生队列负载后，其他消费者才能继续消费。

例如队列 q3 目前是分配给消费者 C2 进行消费，已将拉取了 32 条消息在线程池中处理，然后对消费者进行了扩容，分配给 C2 的 q3 队列，被分配给 C3 了，由于 C2 已将处理了一部分，位点信息还没有提交，如果 C3 立马去消费 q3 队列中的消息，那存在一部分数据会被重复消费，故在 C2 消费者在消费 q3 队列的时候，消息没有消费完成，那负载队列就不能丢弃该队列，就不会在 broker 端释放琐，其他消费者就无法从该队列消费，尽最大可能保证了消息的重复消费，保证顺序性语义

消费总结：

创建消息拉取任务时，消息客户端向 broker 端申请锁定 MessageQueue，使得一个 MessageQueue 同一个时刻只能被一个消费客户端消费
消息消费时，多线程针对同一个消息队列的消费先尝试使用 synchronized 申请独占锁，加锁成功才能进行消费，使得一个 MessageQueue 同一个时刻只能被一个消费客户端中一个线程消费
RocketMQ 中每一个消费组一个单独的线程池并发消费拉取到的消息，即消费端是多线程消费。而顺序消费的并发度等于该消费者分配到的队列数。消费并行度理论上不会有太大问题，因为 MessageQueue 的数量可以调整。
在消费的过程中，会对处理队列 (ProccessQueue) 进行加锁，保证处理中的消息消费完成
顺序消息一旦消费失败，默认会一直重试，不会跳过，因为一旦跳过就失去顺序消息的语义了

顺序消息可能存在的问题

消息阻塞

在顺序性语义的要求下，如果一条消息没有被成功消费，下一条消息就不能被消费，否则就不是顺序消费了。一条消息失败，如果跳过去消费其他消息，那就违背了顺序消费的语义。

建议在使用顺序消息时，务必保证应用能够及时监控并处理消费失败的情况，避免阻塞现象的发生。可以提供一些策略，由用户根据错误类型来决定是否跳过，并且提供重试队列之类的功能，在跳过之后用户可以在“其他”地方重新消费到这条消息。

failover 失效

发送顺序消息无法利用集群的 Failover 特性，因为不能更换 MessageQueue 进行重试

参考

自顶向下学习 RocketMQ（四）：顺序消息

Tue, 21 Dec 2021 10:09:10 +0000

顺序消息

顺序消息是消息队列 RocketMQ 提供的一种对消息发送和消费顺序有严格要求的消息。对于一个指定的 Topic，消息严格按照先进先出（FIFO）的原则进行消息发布和消费，即先发布的消息先消费，后发布的消息后消费。

顺序消息分为 分区顺序消息 和 全局顺序消息

分区顺序消息

“

分区顺序对于指定的一个 Topic，所有消息根据 sharding key 进行区块分区。同一个分区内的消息按照严格的 FIFO 顺序进行发布和消费。Sharding key 是顺序消息中用来区分不同分区的关键字段，和普通消息的 Key 是完全不同的概念。适用场景：性能要求高，以 sharding key 作为分区字段，在同一个区块中严格的按照 FIFO 原则进行消息发布和消费的场景。

”

Sharding Key：顺序消息中用来区分 Topic 中不同分区的关键字段，和普通消息的 Key 是完全不同的概念。消息队列 RocketMQ 会将设置了相同 Sharding Key 的消息路由到同一个分区下，同一个分区内的消息将按照消息发布顺序进行消费。
分区：即 Topic Partition，每个 Topic 包含一个或多个分区，Topic 中的消息会分布在这些不同的分区中。本文中的逻辑分区指的就是 Topic 的分区。
物理分区：区别于逻辑分区，消息实际存储的单元，每个物理分区都会分配到某一台机器指定节点上。

一般场景下，消息的发送顺序和消息生产的绝对时间顺序保持一致，生产者需要自己保证消息发送的顺序和生产顺序一致，建议使用单线程发送，若使用多线程发送消息，可能会造成消息发送顺序乱序。

Topic 中的每个逻辑分区可以对应多个物理分区，当消息按照顺序发送到 Topic 中的逻辑分区时，每个分区的消息将按照负载均匀的存储到对应的多个物理分区中，在物理分区中消息的存储可以不用保持顺序，但消息队列 RocketMQ 会记录消息在逻辑分区和物理分区中的映射关系及存储位置。

即使同一逻辑分区的消息被存储在不同的物理分区中且没有保持消息的顺序，消息队列 RocketMQ 服务端在投递消息时，最终还是会按照消息在逻辑队列中存储的顺序投递给 Consumer，Consumer 消费消息时，同一 Sharding Key 的消息使用单并发消费，保证消息消费顺序和存储顺序一致，最终实现消费顺序和发布顺序的一致

适用场景

适用于性能要求高，以 Sharding Key 作为分区字段，在同一个区块中严格地按照先进先出（FIFO）原则进行消息发布和消费的场景。

业务例子

用户注册需要发送验证码，以用户 ID 作为 Sharding Key，那么同一个用户发送的消息都会按照发布的先后顺序来消费。
电商的订单创建，以订单 ID 作为 Sharding Key，那么同一个订单相关的创建订单消息、订单支付消息、订单退款消息、订单物流消息都会按照发布的先后顺序来消费。

示例

代码依然使用 SpringCloud 整合 RocketMq 的方式

不同于之前文章中使用默认的 input output ，本例中我们使用自定义的方式来实现：

首先声明 Source 接口，注意这个接口不用实现，框架会有默认实现

1public interface MySource {
2
3 @Output("output-order")
4 MessageChannel output4Order();
5}

在消息发送时引入

1@Autowired
2private MySource mySource;

发送消息，消息内容为 order 实体：

 1 // 发送 3 条相同 id 的消息
 2Long id = new Random().nextLong();
 3for (int i = 0; i < 3; i++) {
 4 // 创建 Message
 5 Order order = Order.builder().id(id).desc("test").build();
 6
 7 Message message = MessageBuilder.createMessage(order, new MessageHeaders(headers));
 8 mySource.output4Order().send(message);
 9 System.out.println("发送了消息 " + message);
10}

配置文件

 1spring:
 2 mvc:
 3 throw-exception-if-no-handler-found: true # 处理 404 问题
 4 resources:
 5 add-mappings: false # 关闭 404 资源映射
 6 application:
 7 name: mq-example
 8 cloud:
 9 stream:
10 bindings:
11 # 定义 name 为 input 的 binding 消费
12 input:
13 content-type: application/json
14 destination: test-topic
15 group: consumer-group
16 # 定义 name 为 output 的 binding 生产
17 output-order:
18 content-type: application/json
19 destination: test-topic
20 # Producer 配置项，对应 ProducerProperties 类
21 producer:
22 partition-key-expression: payload['id'] # 分区 key 表达式。该表达式基于 Spring EL，从消息中获得分区 key。
23 rocketmq:
24 # RocketMQ Binder 配置项，对应 RocketMQBinderConfigurationProperties 类
25 binder:
26 # 配置 rocketmq 的 nameserver 地址
27 name-server: 127.0.0.1:9876
28 bindings:
29 output-order:
30 # RocketMQ Producer 配置项，对应 RocketMQProducerProperties 类
31 producer:
32 group: producer-group # 生产者分组
33 sync: true # 是否同步发送消息，默认为 false 异步。
34 input:
35 # RocketMQ Consumer 配置项，对应 RocketMQConsumerProperties 类
36 consumer:
37 enabled: true # 是否开启消费，默认为 true
38 broadcasting: false # 是否使用广播消费，默认为 false 使用集群消费
39 orderly: true # 是否顺序消费，默认为 false 并发消费。

为了方便这里我将生产和消息端的配置写在一起了，实际上生产的情况应该是分开的。

注意几点：

由于是顺序消息，producer 要配置成同步发送
partition-key-expression，如果我们想从消息的 headers 中获得 Sharding key，可以设置为 headers[‘partitionKey’]
orderly 消费时要配置成顺序消费

最后可以输出一下结果，看一下线程 ID 和队列 ID

1 @StreamListener("input")
2 public void receiveInput1(String receiveMsg, GenericMessage message, @Headers Map headers) {
3
4 System.out.println(message.toString());
5 System.out.println("线程 ID: " + Thread.currentThread().getId() + " 接受到消息 input receive: " + receiveMsg);
6 }

列队 ID 相同，证明是顺序消费。

全局顺序消息

“

全局顺序对于指定的一个 Topic，所有消息按照严格的先入先出（FIFO）的顺序进行发布和消费。适用场景：性能要求不高，所有的消息严格按照 FIFO 原则进行消息发布和消费的场景

”

默认 Topic 对应多个队列，当设置 Topic 只有 1 个队列可以实现全局有序，创建 Topic 时手动设置。此类场景极少，性能差，通常不推荐使用。

适用场景

适用于性能要求不高，所有的消息严格按照 FIFO 原则来发布和消费的场景。

示例

在证券处理中，以人民币兑换美元为 Topic，在价格相同的情况下，先出价者优先处理，则可以按照 FIFO 的方式发布和消费全局顺序消息。

常见问题

同一条消息是否可以既是顺序消息，又是定时消息和事务消息？

不可以。顺序消息、定时消息、事务消息是不同的消息类型，三者是互斥关系，不能叠加在一起使用。

顺序消息支持哪种消息发送方式？

顺序消息只支持可靠同步发送方式，不支持异步发送方式，否则将无法严格保证顺序。

顺序消息是否支持集群消费和广播消费？

顺序消息暂时仅支持集群消费模式，不支持广播消费模式。

参考

自顶向下学习 RocketMQ（三）：消息存储

Wed, 08 Dec 2021 10:34:01 +0000

前言

通过前面两篇中的应用例子，我们已经大概知道 RocketMQ 的架构是什么样的了。如图：

主要是以下几个部分：

producer
consumer
broker
nameserver

如果你自己动手部署过 RocketMQ, 相信对下面的这个部署架构图会非常清楚：

本文我们来了解一下 RockerMQ 中的消息存储是如何设计和实现的。

消息存储

前知识

在介绍之前我们先了解几个基本概念：

分区

消息队列中同一个 topic 中的消息可能会存储到多个分区上，如下图：

offset

消息在 broker 上的每个分区都是组织成一个文件列表，消费者拉取数据需要知道数据在文件中的偏移量，这个偏移量就是所谓 offset。Offset 是绝对偏移量，服务器会将 offset 转化为具体文件的相对偏移量 , 消费者消费消息队列的偏移量 , 通过 offset 找到 message

存储架构

消息存储是 RocketMQ 中最为复杂和最为重要的一部分。

上面这个图我们可以更简化一下：

RocketMQ 为 Producer 和 Consumer 分别设计了不同的存储结构，Producer 对应 CommitLog, Consumer 对应 ConsumeQueue。

这其实是“异步化“，或者说”离线计算“的一个典型例子。这里之所以可以用“异步线程”，也是因为消息队列天生就是用来“缓冲消息”的。只要消息到了 CommitLog，发送的消息也就不会丢。只要消息不丢，那就有了“充足的回旋余地”，用一个后台线程慢慢同步到 ConsumeQueue，再由 Consumer 消费。可以说，这也是在消息队列内部的一个典型的“最终一致性”的案例：Producer 发了消息，进了 CommitLog，此时 Consumer 并不可见。但没关系，只要消息不丢，消息最终肯定会进入 ConsumeQueue，让 Consumer 可见。

CommitLog

消息主体以及元数据的存储主体，存储 Producer 端写入的消息主体内容，消息内容不是定长的。

生成规则

CommitLog 单个文件大小默认 1G, 文件名长度为 20 位，左边补零，剩余为起始偏移量，比如 00000000000000000000 代表了第一个文件，起始偏移量为 0，文件大小为 1G=1073741824；当第一个文件写满了，第二个文件为 00000000001073741824，起始偏移量为 1073741824，以此类推。消息主要是顺序写入日志文件，当文件满了，写入下一个文件。

存储路径

 1❯ cd ~/store
 2
 3~/store
 4❯ ll
 5total 16
 6-rw-r--r-- 1 root staff 0B Dec 6 10:48 abort
 7-rw-r--r-- 1 root staff 4.0K Dec 6 15:46 checkpoint
 8drwxr-xr-x 3 root staff 96B Sep 7 16:30 commitlog
 9drwxr-xr-x 12 root staff 384B Dec 6 15:46 config
10drwxr-xr-x 5 root staff 160B Nov 30 14:06 consumequeue
11drwxr-xr-x 3 root staff 96B Dec 6 11:46 index
12-rw-r--r-- 1 root staff 4B Dec 6 11:46 lock

存储规则

RocketMQ 采用了单一的日志文件，即把同一台机器上面所有 topic 的消息，存放在一个文件里面，从而避免了随机的磁盘写入，提高了性能。

RocketMQ 中主要保存了 CommitLog、Consume Queue、Index File 三种数据文件。由于内存和磁盘都是有限的资源，Broker 不可能永久地保存所有数据，所以一些超过保存期限的数据会被定期删除。RocketMQ 通过设置数据过期时间来删除额外的数据文件。

什么样的文件可以被删除？

如果非当前写文件在一定时间间隔内没有再次被更新，则认为是过期文件，可以被删除。

RocketMQ 不会管这个这个文件上的消息是否被全部消费。默认每个文件的过期时间为 72 小时。

1 // The number of hours to keep a log file before deleting it (in hours)
2 @ImportantField
3 private int fileReservedTime = 72;

通过在 Broker 配置文件中设置 fileReservedTime 来改变过期时间，单位为小时

1brokerClusterName = DefaultCluster
2brokerName = broker-a
3brokerId = 0
4deleteWhen = 04
5fileReservedTime = 48
6brokerRole = ASYNC_MASTER
7flushDiskType = ASYNC_FLUSH

删除的整体流程是在 DefaultMessageStore 中启动了一个定时任务来执行的删除操作：

这个定时的周期是 10 秒，每 10 秒会执行一次，可以通过修改参数配置。

1// Resource reclaim interval
2//private int cleanResourceInterval = 10000;
3
4 this.scheduledExecutorService.scheduleAtFixedRate(new Runnable() {
5 @Override
6 public void run() {
7 DefaultMessageStore.this.cleanFilesPeriodically();
8 }
9 }, 1000 * 60, this.messageStoreConfig.getCleanResourceInterval(), TimeUnit.MILLISECONDS);

具体逻辑是这样的：

 1 private void deleteExpiredFiles() {
 2
 3 int deleteCount = 0;
 4 long fileReservedTime = DefaultMessageStore.this.getMessageStoreConfig().getFileReservedTime();
 5 int deletePhysicFilesInterval = DefaultMessageStore.this.getMessageStoreConfig().getDeleteCommitLogFilesInterval();
 6 int destroyMapedFileIntervalForcibly = DefaultMessageStore.this.getMessageStoreConfig().getDestroyMapedFileIntervalForcibly();
 7
 8 boolean timeup = this.isTimeToDelete();
 9 boolean spacefull = this.isSpaceToDelete();
10 boolean manualDelete = this.manualDeleteFileSeveralTimes > 0;
11
12 if (timeup || spacefull || manualDelete) {
13
14 if (manualDelete)
15 this.manualDeleteFileSeveralTimes--;
16
17 boolean cleanAtOnce = DefaultMessageStore.this.getMessageStoreConfig().isCleanFileForciblyEnable() && this.cleanImmediately;
18
19 log.info("begin to delete before {} hours file. timeup: {} spacefull: {} manualDeleteFileSeveralTimes: {} cleanAtOnce: {}",
20 fileReservedTime,
21 timeup,
22 spacefull,
23 manualDeleteFileSeveralTimes,
24 cleanAtOnce);
25
26 fileReservedTime *= 60 * 60 * 1000;
27
28 deleteCount = DefaultMessageStore.this.commitLog.deleteExpiredFile(fileReservedTime, deletePhysicFilesInterval,
29 destroyMapedFileIntervalForcibly, cleanAtOnce);
30 if (deleteCount > 0) {
31 } else if (spacefull) {
32 log.warn("disk space will be full soon, but delete file failed.");
33 }
34 }
35}

可以看到，当满足以下三个条件之一时，将执行删除操作：

当前时间等于已经配置的删除时间，默认为凌晨 4 点，开始执行删除文件操作
```
1// When to delete,default is at 4 am
2 @ImportantField
3 private String deleteWhen = "04";
```

磁盘使用空间超过 85%

1private final double diskSpaceCleanForciblyRatio =
2 Double.parseDouble(System.getProperty("rocketmq.broker.diskSpaceCleanForciblyRatio", "0.85"));

手动执行删除，预留，可以通过调用 excuteDeleteFilesManualy 方法手工触发过期文件删除，目前 RocketMQ 暂未封装手工触发文件删除的命令。

数据结构

从源码上直接看一下 CommitLog 存储时逻辑上的数据结构情况（代码源自 CommitLog 类）：

 1protected PutMessageResult encode(MessageExtBrokerInner msgInner) {
 2 /**
 3 * Serialize message
 4 */
 5 final byte[] propertiesData =
 6 msgInner.getPropertiesString() == null ? null : msgInner.getPropertiesString().getBytes(MessageDecoder.CHARSET_UTF8);
 7
 8 final int propertiesLength = propertiesData == null ? 0 : propertiesData.length;
 9
10 if (propertiesLength > Short.MAX_VALUE) {
11 log.warn("putMessage message properties length too long. length={}", propertiesData.length);
12 return new PutMessageResult(PutMessageStatus.PROPERTIES_SIZE_EXCEEDED, null);
13 }
14
15 final byte[] topicData = msgInner.getTopic().getBytes(MessageDecoder.CHARSET_UTF8);
16 final int topicLength = topicData.length;
17
18 final int bodyLength = msgInner.getBody() == null ? 0 : msgInner.getBody().length;
19
20 final int msgLen = calMsgLength(msgInner.getSysFlag(), bodyLength, topicLength, propertiesLength);
21
22 // Exceeds the maximum message
23 if (msgLen > this.maxMessageSize) {
24 CommitLog.log.warn("message size exceeded, msg total size: " + msgLen + ", msg body size: " + bodyLength
25 + ", maxMessageSize: " + this.maxMessageSize);
26 return new PutMessageResult(PutMessageStatus.MESSAGE_ILLEGAL, null);
27 }
28
29 // Initialization of storage space
30 this.resetByteBuffer(encoderBuffer, msgLen);
31 // 1 TOTALSIZE
32 this.encoderBuffer.putInt(msgLen);
33 // 2 MAGICCODE
34 this.encoderBuffer.putInt(CommitLog.MESSAGE_MAGIC_CODE);
35 // 3 BODYCRC
36 this.encoderBuffer.putInt(msgInner.getBodyCRC());
37 // 4 QUEUEID
38 this.encoderBuffer.putInt(msgInner.getQueueId());
39 // 5 FLAG
40 this.encoderBuffer.putInt(msgInner.getFlag());
41 // 6 QUEUEOFFSET, need update later
42 this.encoderBuffer.putLong(0);
43 // 7 PHYSICALOFFSET, need update later
44 this.encoderBuffer.putLong(0);
45 // 8 SYSFLAG
46 this.encoderBuffer.putInt(msgInner.getSysFlag());
47 // 9 BORNTIMESTAMP
48 this.encoderBuffer.putLong(msgInner.getBornTimestamp());
49 // 10 BORNHOST
50 socketAddress2ByteBuffer(msgInner.getBornHost() ,this.encoderBuffer);
51 // 11 STORETIMESTAMP
52 this.encoderBuffer.putLong(msgInner.getStoreTimestamp());
53 // 12 STOREHOSTADDRESS
54 socketAddress2ByteBuffer(msgInner.getStoreHost() ,this.encoderBuffer);
55 // 13 RECONSUMETIMES
56 this.encoderBuffer.putInt(msgInner.getReconsumeTimes());
57 // 14 Prepared Transaction Offset
58 this.encoderBuffer.putLong(msgInner.getPreparedTransactionOffset());
59 // 15 BODY
60 this.encoderBuffer.putInt(bodyLength);
61 if (bodyLength > 0)
62 this.encoderBuffer.put(msgInner.getBody());
63 // 16 TOPIC
64 this.encoderBuffer.put((byte) topicLength);
65 this.encoderBuffer.put(topicData);
66 // 17 PROPERTIES
67 this.encoderBuffer.putShort((short) propertiesLength);
68 if (propertiesLength > 0)
69 this.encoderBuffer.put(propertiesData);
70
71 encoderBuffer.flip();
72 return null;
73}

结合上表，一条消息的存储内容如下：

将所有的消息存储在一起就是 CommitLog 的全部内容，如下：

注意以上图中所画为抽象结构，具体实现上 commitLog 内部还有

MappedFile
MappedFileQueue

 1public class CommitLog {
 2 // Message's MAGIC CODE daa320a7
 3 public final static int MESSAGE_MAGIC_CODE = -626843481;
 4 protected static final InternalLogger log = InternalLoggerFactory.getLogger(LoggerName.STORE_LOGGER_NAME);
 5 // End of file empty MAGIC CODE cbd43194
 6 protected final static int BLANK_MAGIC_CODE = -875286124;
 7 protected final MappedFileQueue mappedFileQueue;
 8 protected final DefaultMessageStore defaultMessageStore;
 9 
10
11public class MappedFileQueue {
12 private static final InternalLogger log = InternalLoggerFactory.getLogger(LoggerName.STORE_LOGGER_NAME);
13 private static final InternalLogger LOG_ERROR = InternalLoggerFactory.getLogger(LoggerName.STORE_ERROR_LOGGER_NAME);
14
15 private static final int DELETE_FILES_BATCH_MAX = 10;
16
17 private final String storePath;
18
19 protected final int mappedFileSize;
20
21 protected final CopyOnWriteArrayList<MappedFile> mappedFiles = new CopyOnWriteArrayList<MappedFile>();

CommitLog MappedFileQueue MappedFile 三者的关系如下：

MappedFile 和物理文件是一一对应的。

这一点我们可以从 MappedFileQueue 的 load 方法中看出：

 1public boolean load() {
 2
 3 File dir = new File(this.storePath);
 4 File[] ls = dir.listFiles();
 5 if (ls != null) {
 6 return doLoad(Arrays.asList(ls));
 7 }
 8 return true;
 9}
10
11public boolean doLoad(List<File> files) {
12 // ascending order
13 files.sort(Comparator.comparing(File::getName));
14
15 for (File file : files) {
16 if (file.length() != this.mappedFileSize) {
17 log.warn(file + "\t" + file.length()
18 + " length not matched message store config value, ignore it");
19 return true;
20 }
21
22 try {
23 MappedFile mappedFile = new MappedFile(file.getPath(), mappedFileSize);
24
25 mappedFile.setWrotePosition(this.mappedFileSize);
26 mappedFile.setFlushedPosition(this.mappedFileSize);
27 mappedFile.setCommittedPosition(this.mappedFileSize);
28 this.mappedFiles.add(mappedFile);
29 log.info("load " + file.getPath() + " OK");
30 } catch (IOException e) {
31 log.error("load file " + file + " error", e);
32 return false;
33 }
34 }
35 return true;
36}

ConsumeQueue

上文我们讲了 RocketMQ 将所有 topic 的消息都存储在 CommitLog 中，由于是顺序写所以性能比较好，那么随之而来的问题就是查询或者说读取消息的时候怎么办？用这个结构存储效率高，但如果用这个结构读取消息看起来不方便，那 RocketMQ 是怎么做的呢？

如果你本地有 commitLog 文件，可以直接读取一下看看数据：

 1 public static ByteBuffer read(String path) throws Exception {
 2 File file = new File(path);
 3 FileInputStream fin = new FileInputStream(file);
 4 byte[] bytes = new byte[(int) file.length()];
 5 fin.read(bytes);
 6 ByteBuffer buffer = ByteBuffer.wrap(bytes);
 7 return buffer;
 8 }
 9
10 public static void main(String[] args) throws Exception {
11 String filePath = "/Users/xiaohezi/store/commitlog/00000000000000000000";
12 ByteBuffer buffer = read(filePath);
13 List<MessageExt> messageList = new ArrayList<>();
14 while (true) {
15 MessageExt decodeMsgs = MessageDecoder.decode(buffer);
16 if (decodeMsgs == null) {
17 break;
18 }
19 messageList.add(decodeMsgs);
20 }
21 for (MessageExt ms : messageList) {
22 System.out.println("主题：" + ms.getTopic() + " 消息：" +
23 new String(ms.getBody()) + "队列 ID:" + ms.getQueueId() + " 存储地址：" + ms.getStoreHost());
24 }
25 }

程序执行的效率其实并不低，那么 RocketMQ 是怎样进行高效的检索消息的呢？

为了说清楚这个问题，我们先来看个基本概念

MessageQueue

先来个图直观地感受一下：

所谓 MessageQueue 虽然直译是“消息队列”，但它和我们所理解的 “分片”、“分区” 是一回事儿。以后提到 RocketMQ 的分区、分片、队列其实都是对应 messageQueue。

比如我们的 Topic 里面有 100 条数据，该 Topic 默认是 4 个队列，那么每个队列中大约 25 条数据。然后，这些 MessageQueue 是和 Broker 绑定在一起的，就是说每个 MessageQueue 都可能处于不同的 Broker 机器上，这取决于你的队列数量和 Broker 集群。

既然 MessageQueue 是多个，那么在消息发送的时候，势必要通过某种方式选择一个队列。默认的情况下，就是通过轮询来获取一个消息队列。

在消息发送时候的应用如下面引用的官方文档所述：

“

Producer 端在发送消息的时候，会先根据 Topic 找到指定的 TopicPublishInfo，在获取了 TopicPublishInfo 路由信息后，RocketMQ 的客户端在默认方式下 selectOneMessageQueue() 方法会从 TopicPublishInfo 中的 messageQueueList 中选择一个队列（MessageQueue）进行发送消息。具体的容错策略均在 MQFaultStrategy 这个类中定义。这里有一个 sendLatencyFaultEnable 开关变量，如果开启，在随机递增取模的基础上，再过滤掉 not available 的 Broker 代理。所谓的"latencyFaultTolerance" ，是指对之前失败的，按一定的时间做退避。例如，如果上次请求的 latency 超过 550Lms，就退避 3000Lms；超过 1000L，就退避 60000L；如果关闭，采用随机递增取模的方式选择一个队列（MessageQueue）来发送消息，latencyFaultTolerance 机制是实现消息发送高可用的核心关键所在。

”

1public MessageQueue selectOneMessageQueue() {
2 int index = this.sendWhichQueue.incrementAndGet();
3 int pos = Math.abs(index) % this.messageQueueList.size();
4 if (pos < 0)
5 pos = 0;
6 return this.messageQueueList.get(pos);
7}

consumeQueue

接着我们来看下本节的重点 consumeQueue，先看下它的文件组织结构：

其中 队列 ID，就是以 MessageQueue 队列 ID 命名的。

每个 cosumequeue 文件的名称 fileName，名字长度为 20 位，左边补零，剩余为起始偏移量；比如 00000000000000000000 代表了第一个文件，起始偏移量为 0，文件大小为 600W，当第一个文件满之后创建的第二个文件的名字为 00000000000006000000，起始偏移量为 6000000，以此类推，第三个文件名字为 00000000000012000000，起始偏移量为 12000000，消息存储的时候会顺序写入文件，当文件满了，写入下一个文件。

RocketMQ 的 ConsumeQueue 中不存储具体的消息，具体的消息由 CommitLog 存储，ConsumeQueue 中只存储路由到该 queue 中的消息在 CommitLog 中的 offset，消息的大小以及消息所属的 tag 的 hash（tagCode），一共只占 20 个字节：

我们可以按照这个格式输出一下 ConsumerQueue 文件的内容：

 1 public static void main(String[] args) throws Exception {
 2
 3 String path = "/Users/root/store/consumequeue/TopicTest/0/00000000000000000000";
 4 ByteBuffer buffer = read(path);
 5 while (true){
 6 long offset = buffer.getLong();
 7 long size = buffer.getInt();
 8 long code = buffer.getLong();
 9 if (size==0){
10 break;
11 }
12 System.out.println("消息长度："+size+" 消息偏移量：" +offset+" tag hashcode:"+code);
13 }
14 System.out.println("--------------------------");
15
16}
17
18消息长度：201 消息偏移量：201 tag hashcode:2598919
19消息长度：201 消息偏移量：1005 tag hashcode:2598919
20消息长度：201 消息偏移量：1809 tag hashcode:2598919
21...

上面输出的结果中，消息偏移量的差值等于 = 消息长度 * 队列长度，具体到本例就是

804(1005-201) = 201 * 4（从 0-3 共 4 个队列）

为什么是这样？因为每个队列的初始偏移量不同，我以我本地 4 个队列（0-3），每个队列只有一个文件（00000000000000000000）为例，则每个文件的初始 offset 为：

队列 0 偏移量 201
队列 1 偏移量 402
队列 2 偏移量 603
队列 3 偏移量 0

当读取一条消息时，会先读 ConsumeQueue，再读 CommitLog。怎么知道消息存储在哪个 CommitLog 文件上？看一下以下两段代码，出自 CommitLog 和 MappedFileQueue 2 个类：

 1 public SelectMappedBufferResult getData(final long offset, final boolean returnFirstOnNotFound) {
 2 int mappedFileSize = this.defaultMessageStore.getMessageStoreConfig().getMappedFileSizeCommitLog();
 3 MappedFile mappedFile = this.mappedFileQueue.findMappedFileByOffset(offset, returnFirstOnNotFound);
 4 if (mappedFile != null) {
 5 int pos = (int) (offset % mappedFileSize);
 6 SelectMappedBufferResult result = mappedFile.selectMappedBuffer(pos);
 7 return result;
 8 }
 9
10 return null;
11 }
12
13/**
14 * Finds a mapped file by offset.
15 *
16 * @param offset Offset.
17 * @param returnFirstOnNotFound If the mapped file is not found, then return the first one.
18 * @return Mapped file or null (when not found and returnFirstOnNotFound is <code>false</code>).
19 */
20public MappedFile findMappedFileByOffset(final long offset, final boolean returnFirstOnNotFound) {
21 try {
22 MappedFile firstMappedFile = this.getFirstMappedFile();
23 MappedFile lastMappedFile = this.getLastMappedFile();
24 if (firstMappedFile != null && lastMappedFile != null) {
25 if (offset < firstMappedFile.getFileFromOffset() || offset >= lastMappedFile.getFileFromOffset() + this.mappedFileSize) {
26 LOG_ERROR.warn("Offset not matched. Request offset: {}, firstOffset: {}, lastOffset: {}, mappedFileSize: {}, mappedFiles count: {}",
27 offset,
28 firstMappedFile.getFileFromOffset(),
29 lastMappedFile.getFileFromOffset() + this.mappedFileSize,
30 this.mappedFileSize,
31 this.mappedFiles.size());
32 } else {
33 int index = (int) ((offset / this.mappedFileSize) - (firstMappedFile.getFileFromOffset() / this.mappedFileSize));
34 MappedFile targetFile = null;
35 try {
36 targetFile = this.mappedFiles.get(index);
37 } catch (Exception ignored) {
38 }
39
40 if (targetFile != null && offset >= targetFile.getFileFromOffset()
41 && offset < targetFile.getFileFromOffset() + this.mappedFileSize) {
42 return targetFile;
43 }
44
45 for (MappedFile tmpMappedFile : this.mappedFiles) {
46 if (offset >= tmpMappedFile.getFileFromOffset()
47 && offset < tmpMappedFile.getFileFromOffset() + this.mappedFileSize) {
48 return tmpMappedFile;
49 }
50 }
51 }
52
53 if (returnFirstOnNotFound) {
54 return firstMappedFile;
55 }
56 }
57 } catch (Exception e) {
58 log.error("findMappedFileByOffset Exception", e);
59 }
60
61 return null;
62}

假设 1073742827 为物理偏移量（物理偏移量也即全局偏移量），则其对应的相对偏移量为 1003（1003 = 1073742827 - 1073741824），并且该偏移量位于第二个 CommitLog。

根据上面的代码，当我们从 commitLog 文件列表根据 consumeQueue 提供的偏移量 offset 就可以锁定具体的 commitLog 文件，然后根据 offset 计算出 position, 可以找到对应的消息。

 1 public SelectMappedBufferResult selectMappedBuffer(int pos) {
 2 int readPosition = getReadPosition();
 3 if (pos < readPosition && pos >= 0) {
 4 if (this.hold()) {
 5 ByteBuffer byteBuffer = this.mappedByteBuffer.slice();
 6 byteBuffer.position(pos);
 7 int size = readPosition - pos;
 8 ByteBuffer byteBufferNew = byteBuffer.slice();
 9 byteBufferNew.limit(size);
10 return new SelectMappedBufferResult(this.fileFromOffset + pos, byteBufferNew, size, this);
11 }
12 }
13
14 return null;
15}

除了通过 offset 找到对应的消息，还要以通过 message ID 查找。

原理是一样的，只不过会先通过 message ID 将偏移量解析出来：

 1public static MessageId decodeMessageId(final String msgId) throws UnknownHostException {
 2 SocketAddress address;
 3 long offset;
 4 int ipLength = msgId.length() == 32 ? 4 * 2 : 16 * 2;
 5
 6 byte[] ip = UtilAll.string2bytes(msgId.substring(0, ipLength));
 7 byte[] port = UtilAll.string2bytes(msgId.substring(ipLength, ipLength + 8));
 8 ByteBuffer bb = ByteBuffer.wrap(port);
 9 int portInt = bb.getInt(0);
10 address = new InetSocketAddress(InetAddress.getByAddress(ip), portInt);
11
12 // offset
13 byte[] data = UtilAll.string2bytes(msgId.substring(ipLength + 8, ipLength + 8 + 16));
14 bb = ByteBuffer.wrap(data);
15 offset = bb.getLong(0);
16
17 return new MessageId(address, offset);
18}

consumeQueue 文件是何时创建并更新的？

ConsumeQueue 是消息消费队列文件，消息达到 commitlog 文件后将被异步转发到消息消费队列，供消息消费者消费。

RocketMQ 的具体做法是，使用 Broker 端的后台服务线程—ReputMessageService 不停地分发请求并异步构建 ConsumeQueue

indexFile

上图中有一个查询类型是通过messageKey 查询。

它是一种模型查询，查询条件是：Topic+Message Key。说起查询，阿里云有一个推荐的消息查询过程：

messagekey 是什么，它的作用又是什么呢？

顾名思义就是消息的一个标识，可以在客户端发送消息时设置，主要用来在业务上区别每条消息的不同，比如一般我们会把 订单 id、用户 id能在业务上达到区别数据的目的是值设置进去，以方便后面的查询。

 1@GetMapping("/produce")
 2public void produceMsg() {
 3
 4 Map<String, Object> headers = Maps.newHashMapWithExpectedSize(16);
 5 headers.put(MessageConst.PROPERTY_TAGS, "test02");
 6 headers.put(MessageConst.PROPERTY_KEYS,"messageKey");
 7
 8 Message message = MessageBuilder.createMessage("Hello RocketMQ!", new MessageHeaders(headers));
 9 output.send(message);
10 System.out.println("发送了消息 " + message);
11
12}

如果我们想根据 messageKey 来查询消息，RocketMQ 是怎么做的呢？

RocketMQ 引入 Hash 索引机制，为消息建立索引，像上文的 messageKey 就是根据索引查询出来的。IndexFile 是消息索引文件，主要存储的是 key 和 offset 的对应关系。

indexFile（索引文件）提供了一种可以通过 key 或时间区间来查询消息的方法。文件名 fileName 是以创建时的时间戳命名的，固定的单个 IndexFile 文件大小约为 400M，一个 IndexFile 可以保存 2000W 个索引。

RocketMQ 的索引文件逻辑结构，类似 JDK 中 HashMap 的实现。索引文件的具体结构如下：

文件由以下几部分组成：

indexHeader
500w 个 hash 槽
2000w 个 index 条目

indexHeader

IndexFile 的头部，占 40 个字节。主要包含以下字段

beginTimestamp：该 IndexFile 文件中包含消息的最小存储时间。
endTimestamp：该 IndexFile 文件中包含消息的最大存储时间。
beginPhyoffset：该 IndexFile 文件中包含消息的最小 CommitLog 文件偏移量。
endPhyoffset：该 IndexFile 文件中包含消息的最大 CommitLog 文件偏移量。
hashSlotcount：该 IndexFile 文件中包含的 hashSlot 的总数。
indexCount：该 IndexFile 文件中已使用的 Index 条目个数。

 1public class IndexHeader {
 2 public static final int INDEX_HEADER_SIZE = 40;
 3 private static int beginTimestampIndex = 0;
 4 private static int endTimestampIndex = 8;
 5 private static int beginPhyoffsetIndex = 16;
 6 private static int endPhyoffsetIndex = 24;
 7 private static int hashSlotcountIndex = 32;
 8 private static int indexCountIndex = 36;
 9 private final ByteBuffer byteBuffer;
10 private AtomicLong beginTimestamp = new AtomicLong(0);
11 private AtomicLong endTimestamp = new AtomicLong(0);
12 private AtomicLong beginPhyOffset = new AtomicLong(0);
13 private AtomicLong endPhyOffset = new AtomicLong(0);
14 private AtomicInteger hashSlotCount = new AtomicInteger(0);
15
16 private AtomicInteger indexCount = new AtomicInteger(1);

slot table

4*500W 的 Slot Table 并不保存真正的索引数据，而是保存每个槽位对应的单向链表的头

索引数据

20*2000W 是真正的索引数据，即一个 Index File 可以保存 2000W 个索引。

怎么给一条消息建议索引？

先是根据 key 计算 hashcode，对 500w 取模，就可以知道位于哪个 hash 槽。indexHead 占了文件的前面的 40 字节。然后每个 hash 槽占 4 个字节。具体在文件的位置是由公式 40 + keyIndex*4 计算得到的。
再计算 index 条目位置，一条消息 hash 槽的位置是根据 key 决定的，index 条目的位置是放入的顺序决定的，这叫顺序写。index 条目首先要跨过 indexHead 和 500w 个 hash 槽的大小。然后根据当前是第几条 index 条目，就放入到第几个位置去。计算公式是：40 个字节的 indexHead+500w 个 * 4 字节的 hash 槽大小 + 当前 index 索引的值 * 20 字节

怎么查询索引文件？

“

“按照 Message Key 查询消息”的方式，RocketMQ 的具体做法是，主要通过 Broker 端的 QueryMessageProcessor 业务处理器来查询，读取消息的过程就是用 topic 和 key 找到 IndexFile 索引文件中的一条记录，根据其中的 commitLog offset 从 CommitLog 文件中读取消息的实体内容。

”

我们发送的消息体中，包含 Message Key 或 Unique Key，那么就会给它们每一个都构建索引，索引文件根据 key 来查询消息的流程主要是：

根据查询的 key 的 hashcode%slotNum 得到具体的槽的位置 (slotNum 是一个索引文件里面包含的最大槽的数目，例如图中所示 slotNum=500w)
根据 slotValue(slot 位置对应的值）查找到索引项列表的最后一项（倒序排列，slotValue 总是指向最新的一个索引项）
遍历索引项列表返回查询时间范围内的结果集（默认一次最大返回的 32 条记录）

 1 public boolean putKey(final String key, final long phyOffset, final long storeTimestamp) {
 2 if (this.indexHeader.getIndexCount() < this.indexNum) {
 3 int keyHash = indexKeyHashMethod(key);
 4 int slotPos = keyHash % this.hashSlotNum;
 5 int absSlotPos = IndexHeader.INDEX_HEADER_SIZE + slotPos * hashSlotSize;
 6
 7 FileLock fileLock = null;
 8
 9 try {
10
11 // fileLock = this.fileChannel.lock(absSlotPos, hashSlotSize,
12 // false);
13 int slotValue = this.mappedByteBuffer.getInt(absSlotPos);
14 if (slotValue <= invalidIndex || slotValue > this.indexHeader.getIndexCount()) {
15 slotValue = invalidIndex;
16 }
17
18 long timeDiff = storeTimestamp - this.indexHeader.getBeginTimestamp();
19
20 timeDiff = timeDiff / 1000;
21
22 if (this.indexHeader.getBeginTimestamp() <= 0) {
23 timeDiff = 0;
24 } else if (timeDiff > Integer.MAX_VALUE) {
25 timeDiff = Integer.MAX_VALUE;
26 } else if (timeDiff < 0) {
27 timeDiff = 0;
28 }
29
30 int absIndexPos =
31 IndexHeader.INDEX_HEADER_SIZE + this.hashSlotNum * hashSlotSize
32 + this.indexHeader.getIndexCount() * indexSize;
33
34 this.mappedByteBuffer.putInt(absIndexPos, keyHash);
35 this.mappedByteBuffer.putLong(absIndexPos + 4, phyOffset);
36 this.mappedByteBuffer.putInt(absIndexPos + 4 + 8, (int) timeDiff);
37 this.mappedByteBuffer.putInt(absIndexPos + 4 + 8 + 4, slotValue);
38
39 this.mappedByteBuffer.putInt(absSlotPos, this.indexHeader.getIndexCount());
40
41 if (this.indexHeader.getIndexCount() <= 1) {
42 this.indexHeader.setBeginPhyOffset(phyOffset);
43 this.indexHeader.setBeginTimestamp(storeTimestamp);
44 }
45
46 if (invalidIndex == slotValue) {
47 this.indexHeader.incHashSlotCount();
48 }
49 this.indexHeader.incIndexCount();
50 this.indexHeader.setEndPhyOffset(phyOffset);
51 this.indexHeader.setEndTimestamp(storeTimestamp);
52
53 return true;
54 } catch (Exception e) {
55 log.error("putKey exception, Key: " + key + " KeyHashCode: " + key.hashCode(), e);
56 } finally {
57 if (fileLock != null) {
58 try {
59 fileLock.release();
60 } catch (IOException e) {
61 log.error("Failed to release the lock", e);
62 }
63 }
64 }
65 } else {
66 log.warn("Over index file capacity: index count = " + this.indexHeader.getIndexCount()
67 + "; index max num = " + this.indexNum);
68 }
69
70 return false;
71}

简单说就是：先是根据 key 计算 hashcode，对 500w 取模，就可以知道位于哪个 hash 槽。根据槽值的内容，再通过计算 index 条目位置，获取到 index 条目，再依次获取上一个 hash 冲突节点的 index 条目。

总结

RocketMQ 文件存储模型层次结构

RocketMQ 存储的文件主要包括 Commitlog 文件、ConsumeQueue 文件、Index 文件。

消息存储是由 ConsumeQueue 和 CommitLog 配合完成。CommitLog 存储消息真正内容的文件。他们都有各自的生成规则、存储路径、数据结构。内部还有与与他们相映射的 java 数据结构如 MappedFile、MappedByteBuffer、MappedFileQueue 等。

“

RocketMQ 采用的是混合型的存储结构，即为 Broker 单个实例下所有的队列共用一个日志数据文件（即为 CommitLog）来存储。RocketMQ 的混合型存储结构（多个 Topic 的消息实体内容都存储于一个 CommitLog 中）针对 Producer 和 Consumer 分别采用了数据和索引部分相分离的存储结构，Producer 发送消息至 Broker 端，然后 Broker 端使用同步或者异步的方式对消息刷盘持久化，保存至 CommitLog 中。只要消息被刷盘持久化至磁盘文件 CommitLog 中，那么 Producer 发送的消息就不会丢失。正因为如此，Consumer 也就肯定有机会去消费这条消息。当无法拉取到消息后，可以等下一次消息拉取，同时服务端也支持长轮询模式，如果一个消息拉取请求未拉取到消息，Broker 允许等待 30s 的时间，只要这段时间内有新消息到达，将直接返回给消费端。这里，RocketMQ 的具体做法是，使用 Broker 端的后台服务线程—ReputMessageService 不停地分发请求并异步构建 ConsumeQueue（逻辑消费队列）和 IndexFile（索引文件）数据。

”

ConsumeQueue（逻辑消费队列）作为消费消息的索引，保存了指定 Topic 下的队列消息在 CommitLog 中的起始物理偏移量 offset，消息大小 size 和消息 Tag 的 HashCode 值。而 IndexFile（索引文件）则只是为了消息查询提供了一种通过 key 或时间区间来查询消息的方法。

最后结合消息的生产、消费与存储来一起看一下这个流程：

参考

自顶向下学习 RocketMQ（二）SpringCloud 整合 RocketMQ

Mon, 06 Dec 2021 10:49:07 +0000

why

上文中我们讨论了 RocketMQ 的安装问题，有些重要的问题忘了说，即：

为什么要用消息队列
消息队列有什么用？
用了消息队列有什么好处？

来讨论为什么之前，先来看一下消息模型，即 “是什么？”，我们引用 RocketMQ 的消息模型：

“

RocketMQ 主要由 Producer、Broker、Consumer 三部分组成，其中 Producer 负责生产消息，Consumer 负责消费消息，Broker 负责存储消息。Broker 在实际部署过程中对应一台服务器，每个 Broker 可以存储多个 Topic 的消息，每个 Topic 的消息也可以分片存储于不同的 Broker。Message Queue 用于存储消息的物理地址，每个 Topic 中的消息地址存储于多个 Message Queue 中。ConsumerGroup 由多个 Consumer 实例构成。

”

可以看到，主要是有 Producer、Broker、Consumer 这三部分。利用这样的模型，一般来说我们可以做到几点应用：

异步
解耦
削峰填谷

异步

相对同步，异步理论上执行的速度更快，效率更高，主线程执行完自己的逻辑然后发一条消息给消息队列就结束了，另外一个异步线程去订阅然后消费这条消息。

解耦

其实异步和解耦关系很密切，如果你把一个业务从同步的改成异步的了，实际上它从业务上就已经解耦了，至于形式上，无论你是用多个微服务进行拆分解耦，还是多个线程进行拆分解耦，都是解耦的。举个比较常见的例子，也是异步场景的，比如电商的用户下单购买后，增加消费积分场景：订单服务主业务逻辑结束后会给消息队列发一条增加消费积分的消息，下游营销服务会去订阅这条消息消费它，异步地执行增加积分的逻辑。

当然解耦后，系统间调用关系从大的业务上是同步的还是异步的，完全是由业务自己决定的。

削峰填谷

说白了，就是根据系统的处理能力来处理信息。在我们没有用消息队列之前，系统接收多少请求就都要处理完响应回去，处理的能力是根据单机或集群的处理能力而定，当然这是有上限的，虽然可以扩展，但可扩展的粒度比较粗：scale out 或 scale up，要么增加机器，要么扩展单机性能。如果我只是有某一类请求有问题处理不过来，其他的没啥事儿，这种扩展粒度就不太合适了。

利用消息队列，我们完全可以实现灵活的扩展，即将更细粒度的请求，解耦抽象为消息，发送到消息队列，让下游服务根据自身的能力去进消费。这里还涉及一个“流控”的问题，即像控制水流的流速一样，我们也要根据上下游系统及消息队列的处理能力来控制消息的流量，以 RocketMQ 为例：

生产者流控，因为 broker 处理能力达到瓶颈
消费者流控，因为消费能力达到瓶颈。

所谓削峰填谷，讲究的是一个平衡，这个平衡是系统和消息队列处理能力与消息流量之间的平衡。峰值的时候控一控让它下来，低谷的时候填一填让它上来，仅此而已。

Spring Cloud Stream

聊完 why, 我们回到本文的正题，既然是 SpringCloud 的整合，那我们先聊一下 SpringCloud 吧。

Spring Cloud 体系内本身是有基于消息驱动的微服务框架的，即 Spring Cloud Stream。

“

Spring Cloud Stream is a framework for building highly scalable event-driven microservices connected with shared messaging systems.

The framework provides a flexible programming model built on already established and familiar Spring idioms and best practices, including support for persistent pub/sub semantics, consumer groups, and stateful partitions.

”

Spring Cloud Stream 提供了消息中间件配置的统一抽象，推出了 publish-subscribe、consumer groups、partition 这些统一的概念，有效的简化了上层研发人员对 MQ 使用的复杂度，让开发人员更多的精力投入到核心业务的处理。

Spring Cloud Stream 解决什么问题？

无感知的使用消息中间件 Stream 解决了开发人员无感知的使用消息中间件的问题，因为 Stream 对消息中间件的进一步封装，可以做到代码层面对中间件的无感知。
中间件和服务的高度解耦 Spring Cloud Stream 进行了配置隔离，只需要调整配置，开发中可以动态的切换中间件（如 rabbitmq 切换为 kafka)，使得微服务开发的高度解耦，服务可以关注更多自己的业务流程。

应用模型

Spring Cloud Stream 由一个中立的中间件内核组成。Spring Cloud Stream 会注入输入和输出的 channels，应用程序通过这些 channels 与外界通信，而 channels 则是通过一个明确的中间件 Binder 与外部 brokers 连接。

列举下 Binder 的实现：

RabbitMQ
Apache Kafka
Amazon Kinesis
Google PubSub (partner maintained)
Solace PubSub+ (partner maintained)
Azure Event Hubs (partner maintained)
Apache RocketMQ (partner maintained)

另外还有一个概念叫 Binding,Binding 在消息中间件与应用程序提供的 Provider 和 Consumer 之间提供了一个桥梁，实现了开发者只需使用应用程序的 Provider 或 Consumer 生产或消费数据即可，屏蔽了开发者与底层消息中间件的接触。Binding 包括 Input Binding 和 Output Binding。

注意这里的 input 和 output 是站在生产者和消费者的角度，而不是 broker 的角度，如果你生产消息，那么对应使用的应该是 output, 如果你消费消息，那么对应使用的应该是 input。

接入 RocketMQ

依赖

使用 SpringCloud SpringBoot SpringCloud Alibaba 的组合，版本信息如下：

1 <spring.boot.version>2.3.2.RELEASE</spring.boot.version>
2 <spring.cloud.version>Hoxton.SR9</spring.cloud.version>
3 <spring.cloud.alibaba.version>2.2.6.RELEASE</spring.cloud.alibaba.version>

依赖包

 1<dependency>
 2 <groupId>org.springframework.boot</groupId>
 3 <artifactId>spring-boot-starter-web</artifactId>
 4</dependency>
 5<dependency>
 6 <groupId>com.alibaba.cloud</groupId>
 7 <artifactId>spring-cloud-starter-stream-rocketmq</artifactId>
 8</dependency>
 9<dependency>
10 <groupId>org.springframework.boot</groupId>
11 <artifactId>spring-boot-starter-actuator</artifactId>
12</dependency>

配置

 1spring:
 2 mvc:
 3 throw-exception-if-no-handler-found: true # 处理 404 问题
 4 resources:
 5 add-mappings: false # 关闭 404 资源映射
 6 application:
 7 name: mq-example
 8 cloud:
 9 stream:
10 bindings:
11 # 定义 name 为 input 的 binding
12 input:
13 content-type: application/json
14 destination: test-topic
15 group: test-group
16 # 定义 name 为 output 的 binding
17 output:
18 content-type: application/json
19 destination: test-topic
20 rocketmq:
21 binder:
22 # 配置 rocketmq 的 nameserver 地址
23 name-server: 127.0.0.1:9876

生产&消费

生产者 controller

 1 @GetMapping("/produce")
 2 public void produceMsg() {
 3
 4 Map<String, Object> headers = new HashMap<>();
 5 headers.put(MessageConst.PROPERTY_TAGS, "test");
 6 Message message = MessageBuilder.createMessage("Hello RocketMQ!", new MessageHeaders(headers));
 7 output.send(message);
 8 System.out.println("发送了消息 "+message);
 9
10 }

消费者订阅

 1@Service
 2public class ReceiveService {
 3
 4 /**
 5 * 订阅消息
 6 * @param receiveMsg
 7 */
 8 @StreamListener("input")
 9 public void receiveInput1(String receiveMsg) {
10 System.out.println(" 接受到消息 input receive: " + receiveMsg);
11 }
12}

测试

首先启动 RocketMQ(nameserver 和 broker) ，然后启动服务，调用 controller 接口发送消息，查看接收到的消息内容。

也可以通过 dashboard 查看消息的接收状态。

参考

自顶向下学习 RocketMQ（一）: QuickStart

Tue, 30 Nov 2021 06:42:12 +0000

安装部署 RocketMQ

采用源码编译安装，注意请提前将 maven 安装调试好。

操作系统 macOS
RocketMQ 版本：4.9.2
Maven 版本 3.3.9
JDK 版本 1.8.0_181

以下安装是单 Master 模式，非集群模式，仅适用于本地开发和测试环境。

下载源码包

1wget https://dlcdn.apache.org/rocketmq/4.9.2/rocketmq-all-4.9.2-source-release.zip

解压源码并进行编译

1> unzip rocketmq-all-4.9.2-source-release.zip
2> cd rocketmq-all-4.9.2/
3> mvn -Prelease-all -DskipTests clean install -U
4> cd distribution/target/rocketmq-4.9.2/rocketmq-4.9.2

启动 Name Server

在上一步的目录下，执行：

 1> nohup sh bin/mqnamesrv &
 2> tail -f ~/logs/rocketmqlogs/namesrv.log
 3
 4021-11-24 16:50:14 INFO main - tls.client.keyPassword = null
 52021-11-24 16:50:14 INFO main - tls.client.certPath = null
 62021-11-24 16:50:14 INFO main - tls.client.authServer = false
 72021-11-24 16:50:14 INFO main - tls.client.trustCertPath = null
 82021-11-24 16:50:14 INFO main - Using JDK SSL provider
 92021-11-24 16:50:15 INFO main - SSLContext created for server
102021-11-24 16:50:15 INFO NettyEventExecutor - NettyEventExecutor service started
112021-11-24 16:50:15 INFO main - Try to start service thread:FileWatchService started:false lastThread:null
122021-11-24 16:50:15 INFO FileWatchService - FileWatchService service started
132021-11-24 16:50:15 INFO main - The Name Server boot success. serializeType=JSON

启动 Broker

1> nohup sh bin/mqbroker -n localhost:9876 &
2> tail -f ~/logs/rocketmqlogs/broker.log 
3
42021-11-24 16:52:22 INFO main - The broker[localhost, 10.3.10.244:10911] boot success. serializeType=JSON and name server is localhost:9876
52021-11-24 16:52:32 INFO BrokerControllerScheduledThread1 - dispatch behind commit log 0 bytes
62021-11-24 16:52:32 INFO BrokerControllerScheduledThread1 - Slave fall behind master: 202890 bytes
72021-11-24 16:52:32 INFO brokerOutApi_thread_2 - register broker[0]to name server localhost:9876 OK
82021-11-24 16:53:02 INFO brokerOutApi_thread_3 - register broker[0]to name server localhost:9876 OK

安装 RocketMQ-Dashboard

可视化工具，可以在浏览器中查看消息队列的状态。

同样用源码安装，当然也可以用 docker 安装。

下载源码包

1 wget https://github.com/apache/rocketmq-dashboard/archive/refs/tags/rocketmq-dashboard-1.0.0.zip

编译运行

1
2> unzip rocketmq-dashboard-1.0.0.zip
3> cd rocketmq-dashboard-rocketmq-dashboard-1.0.0
4> mvn spring-boot:run

这时候会出现如下错误：

 1Caused by: org.apache.rocketmq.remoting.exception.RemotingConnectException: connect to null failed
 2 at org.apache.rocketmq.remoting.netty.NettyRemotingClient.invokeSync(NettyRemotingClient.java:394)
 3 at org.apache.rocketmq.client.impl.MQClientAPIImpl.getBrokerClusterInfo(MQClientAPIImpl.java:1333)
 4 at org.apache.rocketmq.tools.admin.DefaultMQAdminExtImpl.examineBrokerClusterInfo(DefaultMQAdminExtImpl.java:306)
 5 at org.apache.rocketmq.tools.admin.DefaultMQAdminExt.examineBrokerClusterInfo(DefaultMQAdminExt.java:257)
 6 at org.apache.rocketmq.dashboard.service.client.MQAdminExtImpl.examineBrokerClusterInfo(MQAdminExtImpl.java:204)
 7 at org.apache.rocketmq.dashboard.service.client.MQAdminExtImpl$$FastClassBySpringCGLIB$$a15c4ca6.invoke(<generated>)
 8 at org.springframework.cglib.proxy.MethodProxy.invoke(MethodProxy.java:218)
 9 at org.springframework.aop.framework.CglibAopProxy$CglibMethodInvocation.invokeJoinpoint(CglibAopProxy.java:769)
10 at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:163)
11 at org.springframework.aop.framework.CglibAopProxy$CglibMethodInvocation.proceed(CglibAopProxy.java:747)
12 at org.springframework.aop.aspectj.MethodInvocationProceedingJoinPoint.proceed(MethodInvocationProceedingJoinPoint.java:88)
13 at org.apache.rocketmq.dashboard.aspect.admin.MQAdminAspect.aroundMQAdminMethod(MQAdminAspect.java:52)
14 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
15 at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
16 at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
17 at java.lang.reflect.Method.invoke(Method.java:498)

明显是连不上服务器，需要修改配置文件：

1> cd src/main/resources/

打开 application.properties 文件

 1#
 2# Licensed to the Apache Software Foundation (ASF) under one or more
 3# contributor license agreements. See the NOTICE file distributed with
 4# this work for additional information regarding copyright ownership.
 5# The ASF licenses this file to You under the Apache License, Version 2.0
 6# (the "License"); you may not use this file except in compliance with
 7# the License. You may obtain a copy of the License at
 8#
 9# http://www.apache.org/licenses/LICENSE-2.0
10#
11# Unless required by applicable law or agreed to in writing, software
12# distributed under the License is distributed on an "AS IS" BASIS,
13# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
14# See the License for the specific language governing permissions and
15# limitations under the License.
16#
17
18server.address=0.0.0.0
19server.port=8080
20
21### SSL setting
22#server.ssl.key-store=classpath:rmqcngkeystore.jks
23#server.ssl.key-store-password=rocketmq
24#server.ssl.keyStoreType=PKCS12
25#server.ssl.keyAlias=rmqcngkey
26
27#spring.application.index=true
28spring.application.name=rocketmq-dashboard
29spring.http.encoding.charset=UTF-8
30spring.http.encoding.enabled=true
31spring.http.encoding.force=true
32logging.level.root=INFO
33logging.config=classpath:logback.xml
34#if this value is empty,use env value rocketmq.config.namesrvAddr NAMESRV_ADDR | now, you can set it in ops page.default localhost:9876
35rocketmq.config.namesrvAddr=
36#if you use rocketmq version < 3.5.8, rocketmq.config.isVIPChannel should be false.default true
37rocketmq.config.isVIPChannel=
38#timeout for mqadminExt, default 5000ms
39rocketmq.config.timeoutMillis=
40#rocketmq-console's data path:dashboard/monitor
41rocketmq.config.dataPath=/tmp/rocketmq-console/data
42#set it false if you don't want use dashboard.default true
43rocketmq.config.enableDashBoardCollect=true
44#set the message track trace topic if you don't want use the default one
45rocketmq.config.msgTrackTopicName=
46rocketmq.config.ticketKey=ticket
47
48#Must create userInfo file: ${rocketmq.config.dataPath}/users.properties if the login is required
49rocketmq.config.loginRequired=false
50
51#set the accessKey and secretKey if you used acl
52#rocketmq.config.accessKey=
53#rocketmq.config.secretKey=
54rocketmq.config.useTLS=false

根据注释我们得知，需要将 rocketmq.config.namesrvAddr 设置为：localhost:9876, 再次启动成功。

访问：http://localhost:8080/ ，当然你也可以修改地址或者更改端口号。同样是修改 application.properties 文件，修改成类似这样的配置：

1server.port=8083
2server.servlet.context-path=/rocketmq-dashboard

测试消息的发送和接收

1> export NAMESRV_ADDR=localhost:9876
2> sh bin/tools.sh org.apache.rocketmq.example.quickstart.Producer
3 SendResult [sendStatus=SEND_OK, msgId= ...
4
5> sh bin/tools.sh org.apache.rocketmq.example.quickstart.Consumer
6 ConsumeMessageThread_%d Receive New Messages: [MessageExt...

关闭 nameServer 和 broker

1> sh bin/mqshutdown broker
2The mqbroker(36695) is running...
3Send shutdown request to mqbroker(36695) OK
4
5> sh bin/mqshutdown namesrv
6The mqnamesrv(36664) is running...
7Send shutdown request to mqnamesrv(36664) OK

其他高可用部署方式

多 Master 模式
多 Master 多 Slave 模式-异步复制
多 Master 多 Slave 模式-同步双写

具体部署方式可参考：文档

这里贴一个比较完整的生产 K8S 部署方案：

https://cloud.tencent.com/developer/article/1785729

上面这个方案是一个双主双从的配置，每个 statefulset 只有一个副本，每个 Pod 拥有自己的配置文件，根据 RocketMQ 文档的说明来配置，没有什么问题。但当我们要扩展多 Master, 多 Slave 的时候，就会比较麻烦，要再建 Master Slave 对，增加 statefulset。

下面有一个部署技巧可以解决这个的问题。

通过 statefulset 副本扩展集群规模

“

以上 Broker 与 Slave 配对是通过指定相同的 BrokerName 参数来配对，Master 的 BrokerId 必须是 0，Slave 的 BrokerId 必须是大于 0 的数。

”

根据文档得知 Master 和 Slave 是根据 BrokerName 来配对的，所以上面的部署配置中也对同一对的主从设置了相同的 BrokerName。

如果没有配置 BrokerName 有默认值吗？

我们来看下 RocketMQ 的源码：

 1
 2public class BrokerConfig {
 3 private static final InternalLogger log = InternalLoggerFactory.getLogger(LoggerName.COMMON_LOGGER_NAME);
 4
 5 private String rocketmqHome = System.getProperty(MixAll.ROCKETMQ_HOME_PROPERTY, System.getenv(MixAll.ROCKETMQ_HOME_ENV));
 6 @ImportantField
 7 private String namesrvAddr = System.getProperty(MixAll.NAMESRV_ADDR_PROPERTY, System.getenv(MixAll.NAMESRV_ADDR_ENV));
 8 @ImportantField
 9 private String brokerIP1 = RemotingUtil.getLocalAddress();
10 private String brokerIP2 = RemotingUtil.getLocalAddress();
11 @ImportantField
12 private String brokerName = localHostName();
13 @ImportantField
14 private String brokerClusterName = "DefaultCluster";
15
16 */
17 @ImportantField
18 private boolean aclEnable = false;
19
20 private boolean storeReplyMessageEnable = true;
21
22 private boolean autoDeleteUnusedStats = false;
23
24 public static String localHostName() {
25 try {
26 return InetAddress.getLocalHost().getHostName();
27 } catch (UnknownHostException e) {
28 log.error("Failed to obtain the host name", e);
29 }
30
31 return "DEFAULT_BROKER";
32 }

可见，brokerName 有默认值，即如果没有主动 set brokerName，那么获取的是 localhostName。

pod 的 hostname 即为 pod 的名字，如果我们的 pod 名字是 broker-0，那么它的 hostname 就是 broker-0。联系上面 RocketMQ 的源码，brokerName 的值如果不设置拿到的就是 hostname, 即 pod Name。

由于我们部署 RocketMQ 时用的是有状态服务 (statefulset)，statefulset 的 Pod 的命名是有规则的：

“

对于一个拥有 N 个副本的 StatefulSet，Pod 被部署时是按照 {0 …… N-1} 的序号顺序创建的。

”

于是我们就可以利用 statefulset 的命名规则进行集群的扩展了，例如我要设置一个双主双从的集群，那么只需要将 master 和 slave 的 statefulset 的副本数设置为 2 就可以了，结果类似这样：

1rocketmq-broker-master-0 1/1 Running 1 462d
2rocketmq-broker-master-1 1/1 Running 0 462d
3rocketmq-broker-slave-0 1/1 Running 1 462d
4rocketmq-broker-slave-1 1/1 Running 0 462d

可见，根据命名规则 RocketMQ 的 Master 和 Slave 可以根据 brokerName（即 pod name）配对正确。那么如果我想要扩展集群，那么我只需要把 master 和 slave 的 statefulset 的副本数设置为 2、3、4、5… 就可以了。

以上就完成了只需要改两个 statefulset 的副本数就可以扩展集群的操作。一个小技巧分享给大家。