### 文章目录
* [一、MQ介绍](about:blank#MQ_2)
* * [1.1 为什么要用MQ](about:blank#11_MQ_4)
* * [1）应用解耦](about:blank#1_14)
* [2）流量削峰](about:blank#2_26)
* [3）数据分发](about:blank#3_42)
* [1.2 MQ的优点和缺点](about:blank#12_MQ_52)
* [1.3 各种MQ产品的比较](about:blank#13_MQ_76)
* [二、RocketMQ快速入门](about:blank#RocketMQ_83)
* * [2.1 准备工作](about:blank#21__87)
* * [2.1.1 下载RocketMQ](about:blank#211_RocketMQ_89)
* [2.2.2 环境要求](about:blank#222__97)
* [2.2 安装RocketMQ](about:blank#22_RocketMQ_103)
* * [2.2.1 安装步骤](about:blank#221__105)
* [2.2.2 目录介绍](about:blank#222__112)
* [2.3 启动RocketMQ](about:blank#23_RocketMQ_118)
* [2.4 测试RocketMQ](about:blank#24_RocketMQ_154)
* * [2.4.1 发送消息](about:blank#241__156)
* [2.4.2 接收消息](about:blank#242__165)
* [2.5 关闭RocketMQ](about:blank#25_RocketMQ_174)
* [2.6 各角色介绍](about:blank#26__184)
* [2.7 broker配置文件详解](about:blank#27_broker_195)
* [2.8 可视化监控平台搭建](about:blank#28__261)
* * [2.8.1 概述](about:blank#281__263)
* [2.8.2 下载并编译打包](about:blank#282__269)
* [2.8.3 仪表盘使用及配置](about:blank#283__301)
* [三、消息发送与消费示例（Maven）](about:blank#Maven_312)
* * [3.1 基本样例](about:blank#31__348)
* * [3.1.1 消息发送](about:blank#311__350)
* * [1）发送同步消息](about:blank#1_352)
* [2）发送异步消息](about:blank#2_386)
* [3）单向发送消息](about:blank#3_431)
* [3.1.2 消费消息](about:blank#312__460)
* * [1）集群模式（负载均衡）](about:blank#1_462)
* [2）广播模式](about:blank#2_492)
* [3.2 顺序消息](about:blank#32__522)
* * [3.2.1 顺序消息生产](about:blank#321__530)
* [3.2.2 顺序消费消息](about:blank#322__669)
* [3.3 延时消息](about:blank#33__718)
* * [3.3.1 启动消息消费者](about:blank#331__722)
* [3.3.2 发送延时消息](about:blank#332__748)
* [3.3.3 验证](about:blank#333__771)
* [3.3.4 使用限制](about:blank#334__775)
* [3.4 批量消息](about:blank#34__784)
* * [3.4.1 发送批量消息](about:blank#341__788)
* [3.5 过滤消息](about:blank#35__866)
* * [3.5.1 SQL基本语法](about:blank#351_SQL_894)
* [3.5.2 消息生产者](about:blank#352__916)
* [3.5.3 消息消费者](about:blank#353__934)
* [3.6 事务消息](about:blank#36__951)
* * [3.6.1 流程分析](about:blank#361__953)
* * [1）事务消息发送及提交](about:blank#1_962)
* [2）事务补偿](about:blank#2_972)
* [3）事务消息状态](about:blank#3_982)
* [3.6.2 发送事务消息](about:blank#362__990)
* * [1) 创建事务性生产者](about:blank#1__992)
* [2）实现事务的监听接口](about:blank#2_1025)
* [3.6.3 使用限制](about:blank#363__1053)
* [3.7 连接阿里云RocketMQ时配置AK与Secret](about:blank#37_RocketMQAKSecret_1062)
* * [3.7.1 生产者](about:blank#371__1065)
* [3.7.2 消费者](about:blank#372__1111)
* [四、消息发送与消费示例（Spring Boot）](about:blank#Spring_Boot_1153)
* * [4.1 导入依赖](about:blank#41__1154)
* [4.2 生产者](about:blank#42__1164)
* * [4.2.1 application.yaml 配置文件](about:blank#421_applicationyaml__1165)
* [4.2.2 生产者](about:blank#422__1184)
* [4.2 消费者](about:blank#42__1211)
* * [4.2.1 application.yaml 配置文件](about:blank#421_applicationyaml__1212)
* [4.2.2 消费者消息监听器](about:blank#422__1225)
* [五、消息存储](about:blank#_1260)
* * [5.1 存储介质](about:blank#51__1274)
* [5.2 消息存储结构](about:blank#52__1280)
* [5.3 顺序写](about:blank#53__1290)
* [5.4 刷盘机制](about:blank#54__1297)
* * [1）同步刷盘](about:blank#1_1303)
* [2）异步刷盘](about:blank#2_1307)
* [3）配置](about:blank#3_1311)
* [5.5 零拷贝](about:blank#55__1316)
* [六、高可用性机制](about:blank#_1344)
* * [6.1 消息消费高可用](about:blank#61__1355)
* [6.2 消息发送高可用](about:blank#62__1359)
* [6.3 主从复制](about:blank#63__1366)
* * [1）同步复制](about:blank#1_1370)
* [2）异步复制](about:blank#2_1376)
* [3）配置](about:blank#3_1382)
* [4）总结](about:blank#4_1389)
* [七、负载均衡](about:blank#_1397)
* * [7.1 Producer负载均衡](about:blank#71_Producer_1399)
* [7.2 Consumer负载均衡](about:blank#72_Consumer_1408)
* * [1）集群模式](about:blank#1_1410)
* [2）广播模式](about:blank#2_1432)
* [八、消息重试](about:blank#_1441)
* * [8.1 顺序消息的重试](about:blank#81__1443)
* [8.2 无序消息的重试](about:blank#82__1447)
* * [1）重试次数](about:blank#1_1453)
* [2）配置方式](about:blank#2_1472)
* * [消费失败后，重试配置方式](about:blank#_1474)
* [消费失败后，不重试配置方式](about:blank#_1498)
* [自定义消息最大重试次数](about:blank#_1518)
* [获取消息重试次数](about:blank#_1537)
* [3）多消费组重试](about:blank#3_1552)
* [九、死信队列](about:blank#_1555)
* * [9.1 死信特性](about:blank#91__1561)
* [9.2 查看死信信息](about:blank#92__1574)
* [十、消费幂等](about:blank#_1590)
* * [10.1 消费幂等的必要性](about:blank#101__1594)
* [10.2 处理方式](about:blank#102__1610)
* [十一、RocketMQ使用注意事项](about:blank#RocketMQ_1631)
一、MQ介绍
=====================================================================================================================================================================================================================================================================================================================================================================================================================================================
1.1 为什么要用MQ
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
消息队列是一种“先进先出”的数据结构
其应用场景主要包含以下3个方面
### 1）应用解耦
系统的耦合性越高，容错性就越低。以电商应用为例，用户创建订单后，如果耦合调用库存系统、物流系统、支付系统，任何一个子系统出了故障或者因为升级等原因暂时不可用，都会造成下单操作异常，影响用户使用体验。
使用消息队列解耦合，系统的耦合性就会提高了。比如物流系统发生故障，需要几分钟才能来修复，在这段时间内，物流系统要处理的数据被缓存到消息队列中，用户的下单操作正常完成。当物流系统回复后，补充处理存在消息队列中的订单消息即可，终端系统感知不到物流系统发生过几分钟故障。
### 2）流量削峰
应用系统如果遇到系统请求流量的瞬间猛增，有可能会将系统压垮。有了消息队列可以将大量请求缓存起来，分散到很长一段时间处理，这样可以大大提到系统的稳定性和用户体验。
一般情况，为了保证系统的稳定性，如果系统负载超过阈值，就会阻止用户请求，这会影响用户体验，而如果使用消息队列将请求缓存起来，等待系统处理完毕后通知用户下单完毕，这样总不能下单体验要好。
处于经济考量目的：
业务系统正常时段的QPS如果是1000，流量最高峰是10000，为了应对流量高峰配置高性能的服务器显然不划算，这时可以使用消息队列对峰值流量削峰
### 3）数据分发
通过消息队列可以让数据在多个系统更加之间进行流通。数据的产生方不需要关心谁来使用数据，只需要将数据发送到消息队列，数据使用方直接在消息队列中直接获取数据即可
1.2 MQ的优点和缺点
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
优点：解耦、削峰、数据分发
缺点包含以下几点：
* 系统可用性降低
系统引入的外部依赖越多，系统稳定性越差。一旦MQ宕机，就会对业务造成影响。
如何保证MQ的高可用？
* 系统复杂度提高
MQ的加入大大增加了系统的复杂度，以前系统间是同步的远程调用，现在是通过MQ进行异步调用。
如何保证消息没有被重复消费？怎么处理消息丢失情况？那么保证消息传递的顺序性？
* 一致性问题
A系统处理完业务，通过MQ给B、C、D三个系统发消息数据，如果B系统、C系统处理成功，D系统处理失败。
如何保证消息数据处理的一致性？
1.3 各种MQ产品的比较
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
常见的MQ产品包括Kafka、ActiveMQ、RabbitMQ、RocketMQ。
二、RocketMQ快速入门
=============================================================================================================================================================================================================================================================================================================================================================================================================================================================
RocketMQ 是阿里巴巴2016年MQ中间件，使用 Java 语言开发，在阿里内部，RocketMQ 承接了例如“双11”等高并发场景的消息流转，能够处理万亿级别的消息。
2.1 准备工作
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
### 2.1.1 下载RocketMQ
这里选择的 RocketMQ 的版本：4.6.0
下载地址：[下载地址](http://rocketmq.apache.org/dowloading/releases/)
官方文档：[http://rocketmq.apache.org/docs/quick-start/](http://rocketmq.apache.org/docs/quick-start/)
### 2.2.2 环境要求
* Linux64位系统
* JDK1.8(64位)
2.2 安装RocketMQ
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
### 2.2.1 安装步骤
我这里是以二进制包方式来安装的：
1. 解压安装包
2. 进入安装目录
### 2.2.2 目录介绍
* `bin`：启动脚本，包括 shell 脚本和 CMD 脚本
* `conf`：实例配置文件 ，包括 broker 配置文件、logback 配置文件等
* `lib`：依赖 jar 包，包括Netty、commons-lang、FastJSON等
2.3 启动RocketMQ
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
1. `RocketMQ` 默认的虚拟机内存较大，启动 `Broker` 或者 `NameServer` 可能会因为内存不足而导致失败，所以需要编辑如下两个配置文件，修改 JVM 内存大小
```
# 编辑 runbroker.sh 和 runserver.sh 修改默认 JVM 大小
$ vi bin/runbroker.sh
# 参考设置
JAVA_OPT="${JAVA_OPT} -server -Xms256m -Xmx256m -Xmn128m"
$ vi bin/runserver.sh
# 参考设置
JAVA_OPT="${JAVA_OPT} -server -Xms256m -Xmx256m -Xmn128m -XX:MetaspaceSize=128m -XX:MaxMetaspaceSize=320m"
```
2. 启动 `NameServer`
```
# 1.启动NameServer
nohup sh bin/mqnamesrv &
# 2.查看启动日志
tail -f ~/logs/rocketmqlogs/namesrv.log
```
3. 启动 `Broker`
```
# 1.启动Broker
nohup sh bin/mqbroker -n localhost:9876 &
# 2.查看启动日志
tail -f ~/logs/rocketmqlogs/broker.log
```
> `bin/mqbroker` 的一些可选参数：
>
> * `-c`：指定配置文件路径
> * `-n`：NameServer 的地址
2.4 测试RocketMQ
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
### 2.4.1 发送消息
```
# 1.设置环境变量
export NAMESRV_ADDR=localhost:9876
# 2.使用安装包的Demo发送消息
sh bin/tools.sh org.apache.rocketmq.example.quickstart.Producer
```
### 2.4.2 接收消息
```
# 1.设置环境变量
export NAMESRV_ADDR=localhost:9876
# 2.接收消息
sh bin/tools.sh org.apache.rocketmq.example.quickstart.Consumer
```
2.5 关闭RocketMQ
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
```
# 1.关闭NameServer
sh bin/mqshutdown namesrv
# 2.关闭Broker
sh bin/mqshutdown broker
```
2.6 各角色介绍
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
* `Producer`：消息的发送者；举例：发件者
* `Consumer`：消息接收者；举例：收件人
* `Consumer Group`：消费组；每一个 consumer 实例都属于一个 consumer group，每一条消息只会被同一个 consumer group 里的一个 consumer 实例消费。（不同consumer group可以同时消费同一条消息）
* `Broker`：暂存和传输消息；举例：快递公司
* `NameServer`：管理 Broker；举例：快递公司的管理机构
* `Topic`：区分消息的种类；一个发送者可以发送消息给一个或者多个 Topic；一个消息的接收者可以订阅一个或者多个 Topic 消息
* `Message Queue`：相当于是 Topic 的分区；用于并行发送和接收消息
2.7 broker配置文件详解
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
broker 默认的配置文件位置在：`conf/broker.conf`
```
#所属集群名字
brokerClusterName=rocketmq-cluster
#broker名字，注意此处不同的配置文件填写的不一样
brokerName=broker-a
#0 表示 Master，>0 表示 Slave
brokerId=0
#nameServer地址，分号分割
namesrvAddr=rocketmq-nameserver1:9876;rocketmq-nameserver2:9876
#在发送消息时，自动创建服务器不存在的topic，默认创建的队列数
defaultTopicQueueNums=4
#是否允许 Broker 自动创建Topic，建议线下开启，线上关闭
autoCreateTopicEnable=true
#是否允许 Broker 自动创建订阅组，建议线下开启，线上关闭
autoCreateSubscriptionGroup=true
#Broker 对外服务的监听端口
listenPort=10911
#删除文件时间点，默认凌晨 4点
deleteWhen=04
#文件保留时间，默认 48 小时
fileReservedTime=120
#commitLog每个文件的大小默认1G
mapedFileSizeCommitLog=1073741824
#ConsumeQueue每个文件默认存30W条，根据业务情况调整
mapedFileSizeConsumeQueue=300000
#destroyMapedFileIntervalForcibly=120000
#redeleteHangedFileInterval=120000
#检测物理文件磁盘空间
diskMaxUsedSpaceRatio=88
#存储路径
storePathRootDir=/usr/local/rocketmq/store
#commitLog 存储路径
storePathCommitLog=/usr/local/rocketmq/store/commitlog
#消费队列存储路径存储路径
storePathConsumeQueue=/usr/local/rocketmq/store/consumequeue
#消息索引存储路径
storePathIndex=/usr/local/rocketmq/store/index
#checkpoint 文件存储路径
storeCheckpoint=/usr/local/rocketmq/store/checkpoint
#abort 文件存储路径
abortFile=/usr/local/rocketmq/store/abort
#限制的消息大小
maxMessageSize=65536
#flushCommitLogLeastPages=4
#flushConsumeQueueLeastPages=2
#flushCommitLogThoroughInterval=10000
#flushConsumeQueueThoroughInterval=60000
#Broker 的角色
#- ASYNC_MASTER 异步复制Master
#- SYNC_MASTER 同步双写Master
#- SLAVE
brokerRole=SYNC_MASTER
#刷盘方式
#- ASYNC_FLUSH 异步刷盘
#- SYNC_FLUSH 同步刷盘
flushDiskType=SYNC_FLUSH
#checkTransactionMessageEnable=false
#发消息线程池数量
#sendMessageThreadPoolNums=128
#拉消息线程池数量
#pullMessageThreadPoolNums=128
```
2.8 可视化监控平台搭建
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
RocketMq 社区项目：[https://github.com/apache/rocketmq-externals](https://github.com/apache/rocketmq-externals)
### 2.8.1 概述
`RocketMQ` 有一个对其扩展的开源项目 [rocketmq-dashboard](https://github.com/apache/rocketmq-dashboard)，这个便是管理控制台项目了。
GitHub 地址：[https://github.com/apache/rocketmq-dashboard](https://github.com/apache/rocketmq-dashboard)
### 2.8.2 下载并编译打包
1. 克隆项目
```
git clone https://github.com/apache/rocketmq-dashboard.git
```
2. 在 `rocketmq-dashboard` 中配置 `namesrv` 集群地址：
```
$ cd rocketmq-dashboard-master
$ vim src/main/resources/application.properties
rocketmq.config.namesrvAddr=10.211.55.4:9876
```
3. 配置完成进行编译并打包
```
mvn clean package -Dmaven.test.skip=true
```
4. 启动 rocketmq-console：
```
nohup java -jar rocketmq-dashboard-2.0.0.jar > tmp.log &
```
启动成功后，我们就可以通过浏览器访问 `http://IP地址:8080` 进入控制台界面了，如下图：
### 2.8.3 仪表盘使用及配置
使用文档就放在代码中，包括 HTTPS 方式访问Dashboard，登录访问Dashboard，权限检验的详细配置说明
详细请查看：
* GitHub 地址：[https://github.com/apache/rocketmq-dashboard/blob/master/docs/1\_0\_0/UserGuide\_CN.md](https://github.com/apache/rocketmq-dashboard/blob/master/docs/1_0_0/UserGuide_CN.md)
* clone 到本地的文件路径：`docs/1_0_0/UserGuide_CN.md`
三、消息发送与消费示例（Maven）
=================================================================================================================================================================================================================================================================================================================================================================================================================================================================
* 导入MQ客户端依赖
注意：`rocketmq-client` 的版本，要与 `RocketMQ` 的**版本一致**
```
<dependency>
<groupId>org.apache.rocketmq</groupId>
<artifactId>rocketmq-client</artifactId>
<version>4.6.0</version>
</dependency>
```
* 消息发送者步骤分析：
1. 创建消息生产者 `producer`，并指定生产者组名
2. 指定 `Nameserver` 地址
3. 启动 `producer`
4. 创建消息对象，指定主题 `Topic`、`Tag` 和消息体
5. 发送消息
6. 关闭生产者 `producer`
* 消息消费者步骤分析：
1. 创建消费者 `Consumer`，制定消费者组名
2. 指定 `Nameserver` 地址
3. 订阅主题 `Topic` 和 `Tag`
4. 设置回调函数，处理消息
5. 启动消费者 `consumer`
3.1 基本样例
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
### 3.1.1 消息发送
#### 1）发送同步消息
这种可靠性同步地发送方式使用的比较广泛，比如：重要的消息通知，短信通知。
```
public class SyncProducer {
public static void main(String[] args) throws Exception {
// 实例化消息生产者Producer
DefaultMQProducer producer = new DefaultMQProducer("please_rename_unique_group_name");
// 设置NameServer的地址
producer.setNamesrvAddr("localhost:9876");
// 设置消息同步发送失败时的重试次数，默认为 2
producer.setRetryTimesWhenSendFailed(2);
// 设置消息发送超时时间，默认3000ms
producer.setSendMsgTimeout(3000);
// 启动Producer实例
producer.start();
for (int i = 0; i < 100; i++) {
// 创建消息，并指定Topic，Tag和消息体
Message msg = new Message("TopicTest" /* Topic */,
"TagA" /* Tag */,
("Hello RocketMQ " + i).getBytes(RemotingHelper.DEFAULT_CHARSET) /* Message body */
);
// 发送消息到一个Broker
SendResult sendResult = producer.send(msg);
// 通过sendResult返回消息是否成功送达
System.out.printf("%s%n", sendResult);
}
// 如果不再发送消息，关闭Producer实例。
producer.shutdown();
}
}
```
#### 2）发送异步消息
异步消息通常用在对响应时间敏感的业务场景，即发送端不能容忍长时间地等待Broker的响应。
```
public class AsyncProducer {
public static void main(String[] args) throws Exception {
// 实例化消息生产者Producer
DefaultMQProducer producer = new DefaultMQProducer("please_rename_unique_group_name");
// 设置NameServer的地址
producer.setNamesrvAddr("localhost:9876");
// 设置消息异步发送失败时的重试次数，默认为 2
producer.setRetryTimesWhenSendAsyncFailed(2);
// 设置消息发送超时时间，默认3000ms
producer.setSendMsgTimeout(3000);
// 启动Producer实例
producer.start();
producer.setRetryTimesWhenSendAsyncFailed(0);
for (int i = 0; i < 100; i++) {
final int index = i;
// 创建消息，并指定Topic，Tag和消息体
Message msg = new Message("TopicTest",
"TagA",
"OrderID188",
"Hello world".getBytes(RemotingHelper.DEFAULT_CHARSET));
// SendCallback接收异步返回结果的回调
producer.send(msg, new SendCallback() {
@Override
public void onSuccess(SendResult sendResult) {
System.out.printf("%-10d OK %s %n", index,
sendResult.getMsgId());
}
@Override
public void onException(Throwable e) {
System.out.printf("%-10d Exception %s %n", index, e);
e.printStackTrace();
}
});
}
// 如果不再发送消息，关闭Producer实例。
producer.shutdown();
}
}
```
#### 3）单向发送消息
这种方式主要用在不特别关心发送结果的场景，例如日志发送。
```
public class OnewayProducer {
public static void main(String[] args) throws Exception{
// 实例化消息生产者Producer
DefaultMQProducer producer = new DefaultMQProducer("please_rename_unique_group_name");
// 设置NameServer的地址
producer.setNamesrvAddr("localhost:9876");
// 启动Producer实例
producer.start();
for (int i = 0; i < 100; i++) {
// 创建消息，并指定Topic，Tag和消息体
Message msg = new Message("TopicTest" /* Topic */,
"TagA" /* Tag */,
("Hello RocketMQ " + i).getBytes(RemotingHelper.DEFAULT_CHARSET) /* Message body */
);
// 发送单向消息，没有任何返回结果
producer.sendOneway(msg);
}
// 如果不再发送消息，关闭Producer实例。
producer.shutdown();
}
}
```
### 3.1.2 消费消息
#### 1）集群模式（负载均衡）
消费者采用集群方式消费消息，一条消息同一个消费者组中只有一个消费者会消费到
```
public static void main(String[] args) throws Exception {
// 实例化消息生产者,指定组名
DefaultMQPushConsumer consumer = new DefaultMQPushConsumer("group1");
// 指定Namesrv地址信息.
consumer.setNamesrvAddr("localhost:9876");
// 订阅Topic
consumer.subscribe("Test", "*");
//负载均衡模式消费
consumer.setMessageModel(MessageModel.CLUSTERING);
// 注册回调函数，处理消息
consumer.registerMessageListener(new MessageListenerConcurrently() {
@Override
public ConsumeConcurrentlyStatus consumeMessage(List<MessageExt> msgs,
ConsumeConcurrentlyContext context) {
System.out.printf("%s Receive New Messages: %s %n",
Thread.currentThread().getName(), msgs);
return ConsumeConcurrentlyStatus.CONSUME_SUCCESS;
}
});
//启动消息者
consumer.start();
System.out.printf("Consumer Started.%n");
}
```
#### 2）广播模式
消费者采用广播的方式消费消息，一条消息同一个消费者组中每个消费者都要消费
```
public static void main(String[] args) throws Exception {
// 实例化消息生产者,指定组名
DefaultMQPushConsumer consumer = new DefaultMQPushConsumer("group1");
// 指定Namesrv地址信息.
consumer.setNamesrvAddr("localhost:9876");
// 订阅Topic
consumer.subscribe("Test", "*");
//广播模式消费
consumer.setMessageModel(MessageModel.BROADCASTING);
// 注册回调函数，处理消息
consumer.registerMessageListener(new MessageListenerConcurrently() {
@Override
public ConsumeConcurrentlyStatus consumeMessage(List<MessageExt> msgs,
ConsumeConcurrentlyContext context) {
System.out.printf("%s Receive New Messages: %s %n",
Thread.currentThread().getName(), msgs);
return ConsumeConcurrentlyStatus.CONSUME_SUCCESS;
}
});
//启动消息者
consumer.start();
System.out.printf("Consumer Started.%n");
}
```
3.2 顺序消息
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
消息有序指的是可以按照消息的发送顺序来消费(FIFO)。RocketMQ可以严格的保证消息有序，可以分为分区有序或者全局有序。
顺序消费的原理解析，在默认的情况下消息发送会采取Round Robin轮询方式把消息发送到不同的queue(分区队列)；而消费消息的时候从多个queue上拉取消息，这种情况发送和消费是不能保证顺序。但是如果控制发送的顺序消息只依次发送到同一个queue中，消费的时候只从这个queue上依次拉取，则就保证了顺序。当发送和消费参与的queue只有一个，则是全局有序；如果多个queue参与，则为分区有序，即相对每个queue，消息都是有序的。
下面用订单进行分区有序的示例。一个订单的顺序流程是：创建、付款、推送、完成。订单号相同的消息会被先后发送到同一个队列中，消费时，同一个OrderId获取到的肯定是同一个队列。
### 3.2.1 顺序消息生产
```
/**
* Producer，发送顺序消息
*/
public class Producer {
public static void main(String[] args) throws Exception {
DefaultMQProducer producer = new DefaultMQProducer("please_rename_unique_group_name");
producer.setNamesrvAddr("127.0.0.1:9876");
producer.start();
String[] tags = new String[]{"TagA", "TagC", "TagD"};
// 订单列表
List<OrderStep> orderList = new Producer().buildOrders();
Date date = new Date();
SimpleDateFormat sdf = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");
String dateStr = sdf.format(date);
for (int i = 0; i < 10; i++) {
// 加个时间前缀
String body = dateStr + " Hello RocketMQ " + orderList.get(i);
Message msg = new Message("TopicTest", tags[i % tags.length], "KEY" + i, body.getBytes());
SendResult sendResult = producer.send(msg, new MessageQueueSelector() {
@Override
public MessageQueue select(List<MessageQueue> mqs, Message msg, Object arg) {
Long id = (Long) arg; //根据订单id选择发送queue
long index = id % mqs.size();
return mqs.get((int) index);
}
}, orderList.get(i).getOrderId());//订单id
System.out.println(String.format("SendResult status:%s, queueId:%d, body:%s",
sendResult.getSendStatus(),
sendResult.getMessageQueue().getQueueId(),
body));
}
producer.shutdown();
}
/**
* 订单的步骤
*/
private static class OrderStep {
private long orderId;
private String desc;
public long getOrderId() {
return orderId;
}
public void setOrderId(long orderId) {
this.orderId = orderId;
}
public String getDesc() {
return desc;
}
public void setDesc(String desc) {
this.desc = desc;
}
@Override
public String toString() {
return "OrderStep{" +
"orderId=" + orderId +
", desc='" + desc + '\'' +
'}';
}
}
/**
* 生成模拟订单数据
*/
private List<OrderStep> buildOrders() {
List<OrderStep> orderList = new ArrayList<OrderStep>();
OrderStep orderDemo = new OrderStep();
orderDemo.setOrderId(15103111039L);
orderDemo.setDesc("创建");
orderList.add(orderDemo);
orderDemo = new OrderStep();
orderDemo.setOrderId(15103111065L);
orderDemo.setDesc("创建");
orderList.add(orderDemo);
orderDemo = new OrderStep();
orderDemo.setOrderId(15103111039L);
orderDemo.setDesc("付款");
orderList.add(orderDemo);
orderDemo = new OrderStep();
orderDemo.setOrderId(15103117235L);
orderDemo.setDesc("创建");
orderList.add(orderDemo);
orderDemo = new OrderStep();
orderDemo.setOrderId(15103111065L);
orderDemo.setDesc("付款");
orderList.add(orderDemo);
orderDemo = new OrderStep();
orderDemo.setOrderId(15103117235L);
orderDemo.setDesc("付款");
orderList.add(orderDemo);
orderDemo = new OrderStep();
orderDemo.setOrderId(15103111065L);
orderDemo.setDesc("完成");
orderList.add(orderDemo);
orderDemo = new OrderStep();
orderDemo.setOrderId(15103111039L);
orderDemo.setDesc("推送");
orderList.add(orderDemo);
orderDemo = new OrderStep();
orderDemo.setOrderId(15103117235L);
orderDemo.setDesc("完成");
orderList.add(orderDemo);
orderDemo = new OrderStep();
orderDemo.setOrderId(15103111039L);
orderDemo.setDesc("完成");
orderList.add(orderDemo);
return orderList;
}
}
```
### 3.2.2 顺序消费消息
```
/**
* 顺序消息消费，带事务方式（应用可控制Offset什么时候提交）
*/
public class ConsumerInOrder {
public static void main(String[] args) throws Exception {
DefaultMQPushConsumer consumer = new
DefaultMQPushConsumer("please_rename_unique_group_name_3");
consumer.setNamesrvAddr("127.0.0.1:9876");
/**
* 设置Consumer第一次启动是从队列头部开始消费还是队列尾部开始消费<br>
* 如果非第一次启动，那么按照上次消费的位置继续消费
*/
consumer.setConsumeFromWhere(ConsumeFromWhere.CONSUME_FROM_FIRST_OFFSET);
consumer.subscribe("TopicTest", "TagA || TagC || TagD");
consumer.registerMessageListener(new MessageListenerOrderly() {
Random random = new Random();
@Override
public ConsumeOrderlyStatus consumeMessage(List<MessageExt> msgs, ConsumeOrderlyContext context) {
context.setAutoCommit(true);
for (MessageExt msg : msgs) {
// 可以看到每个queue有唯一的consume线程来消费, 订单对每个queue(分区)有序
System.out.println("consumeThread=" + Thread.currentThread().getName() + "queueId=" + msg.getQueueId() + ", content:" + new String(msg.getBody()));
}
try {
//模拟业务逻辑处理中...
TimeUnit.SECONDS.sleep(random.nextInt(10));
} catch (Exception e) {
e.printStackTrace();
}
return ConsumeOrderlyStatus.SUCCESS;
}
});
consumer.start();
System.out.println("Consumer Started.");
}
}
```
3.3 延时消息
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
比如电商里，提交了一个订单就可以发送一个延时消息，1h后去检查这个订单的状态，如果还是未付款就取消订单释放库存。
### 3.3.1 启动消息消费者
```
public class ScheduledMessageConsumer {
public static void main(String[] args) throws Exception {
// 实例化消费者
DefaultMQPushConsumer consumer = new DefaultMQPushConsumer("ExampleConsumer");
// 订阅Topics
consumer.subscribe("TestTopic", "*");
// 注册消息监听者
consumer.registerMessageListener(new MessageListenerConcurrently() {
@Override
public ConsumeConcurrentlyStatus consumeMessage(List<MessageExt> messages, ConsumeConcurrentlyContext context) {
for (MessageExt message : messages) {
// Print approximate delay time period
System.out.println("Receive message[msgId=" + message.getMsgId() + "] " + (System.currentTimeMillis() - message.getStoreTimestamp()) + "ms later");
}
return ConsumeConcurrentlyStatus.CONSUME_SUCCESS;
}
});
// 启动消费者
consumer.start();
}
}
```
### 3.3.2 发送延时消息
```
public class ScheduledMessageProducer {
public static void main(String[] args) throws Exception {
// 实例化一个生产者来产生延时消息
DefaultMQProducer producer = new DefaultMQProducer("ExampleProducerGroup");
// 启动生产者
producer.start();
int totalMessagesToSend = 100;
for (int i = 0; i < totalMessagesToSend; i++) {
Message message = new Message("TestTopic", ("Hello scheduled message " + i).getBytes());
// 设置延时等级3,这个消息将在10s之后发送(现在只支持固定的几个时间,详看delayTimeLevel)
message.setDelayTimeLevel(3);
// 发送消息
producer.send(message);
}
// 关闭生产者
producer.shutdown();
}
}
```
### 3.3.3 验证
您将会看到消息的消费比存储时间晚10秒
### 3.3.4 使用限制
```
// org/apache/rocketmq/store/config/MessageStoreConfig.java
private String messageDelayLevel = "1s 5s 10s 30s 1m 2m 3m 4m 5m 6m 7m 8m 9m 10m 20m 30m 1h 2h";
```
现在RocketMq并不支持任意时间的延时，需要设置几个固定的延时等级，从1s到2h分别对应着等级1到18
3.4 批量消息
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
批量发送消息能显著提高传递小消息的性能。限制是这些批量消息应该有相同的topic，相同的waitStoreMsgOK，而且不能是延时消息。此外，这一批消息的总大小不应超过4MB。
### 3.4.1 发送批量消息
如果您每次只发送不超过 `4MB` 的消息，则很容易使用批处理，样例如下：
```
String topic = "BatchTest";
List<Message> messages = new ArrayList<>();
messages.add(new Message(topic, "TagA", "OrderID001", "Hello world 0".getBytes()));
messages.add(new Message(topic, "TagA", "OrderID002", "Hello world 1".getBytes()));
messages.add(new Message(topic, "TagA", "OrderID003", "Hello world 2".getBytes()));
try {
producer.send(messages);
} catch (Exception e) {
e.printStackTrace();
//处理error
}
```
如果消息的总长度可能大于 `4MB` 时，这时候最好把消息进行分割
```
public class ListSplitter implements Iterator<List<Message>> {
private final int SIZE_LIMIT = 1024 * 1024 * 4;
private final List<Message> messages;
private int currIndex;
public ListSplitter(List<Message> messages) {
this.messages = messages;
}
@Override
public boolean hasNext() {
return currIndex < messages.size();
}
@Override
public List<Message> next() {
int nextIndex = currIndex;
int totalSize = 0;
for (; nextIndex < messages.size(); nextIndex++) {
Message message = messages.get(nextIndex);
int tmpSize = message.getTopic().length() + message.getBody().length;
Map<String, String> properties = message.getProperties();
for (Map.Entry<String, String> entry : properties.entrySet()) {
tmpSize += entry.getKey().length() + entry.getValue().length();
}
tmpSize = tmpSize + 20; // 增加日志的开销20字节
if (tmpSize > SIZE_LIMIT) {
//单个消息超过了最大的限制
//忽略,否则会阻塞分裂的进程
if (nextIndex - currIndex == 0) {
//假如下一个子列表没有元素,则添加这个子列表然后退出循环,否则只是退出循环
nextIndex++;
}
break;
}
if (tmpSize + totalSize > SIZE_LIMIT) {
break;
} else {
totalSize += tmpSize;
}
}
List<Message> subList = messages.subList(currIndex, nextIndex);
currIndex = nextIndex;
return subList;
}
}
//把大的消息分裂成若干个小的消息
ListSplitter splitter = new ListSplitter(messages);
while (splitter.hasNext()) {
try {
List<Message> listItem = splitter.next();
producer.send(listItem);
} catch (Exception e) {
e.printStackTrace();
//处理error
}
}
```
3.5 过滤消息
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
在大多数情况下，TAG是一个简单而有用的设计，其可以来选择您想要的消息。例如：
```
DefaultMQPushConsumer consumer = new DefaultMQPushConsumer("CID_EXAMPLE");
consumer.subscribe("TOPIC", "TAGA || TAGB || TAGC");
```
消费者将接收包含TAGA或TAGB或TAGC的消息。但是限制是一个消息只能有一个标签，这对于复杂的场景可能不起作用。在这种情况下，可以使用SQL表达式筛选消息。SQL特性可以通过发送消息时的属性来进行计算。在RocketMQ定义的语法下，可以实现一些简单的逻辑。下面是一个例子：
```
------------
| message |
|----------| a > 5 AND b = 'abc'
| a = 10 | --------------------> Gotten
| b = 'abc'|
| c = true |
------------
------------
| message |
|----------| a > 5 AND b = 'abc'
| a = 1 | --------------------> Missed
| b = 'abc'|
| c = true |
------------
```
### 3.5.1 SQL基本语法
RocketMQ 只定义了一些基本语法来支持这个特性。你也可以很容易地扩展它。
* 数值比较，比如：`>`，`>=`，`<`，`<=`，`BETWEEN`，`=`
* 字符比较，比如：`=`，`<>`，`IN`
* `IS NULL` 或者 `IS NOT NULL`
* 逻辑符号 `AND`，`OR`，`NOT`
常量支持类型为：
* 数值，比如：`123`，`3.1415`
* 字符，比如：`'abc'`，必须用单引号包裹起来
* `NULL`，特殊的常量
* 布尔值，`TRUE` 或 `FALSE`
只有使用 `push` 模式的消费者才能用使用SQL92标准的sql语句，接口如下：
```
public void subscribe(finalString topic, final MessageSelector messageSelector)
```
### 3.5.2 消息生产者
发送消息时，你能通过`putUserProperty`来设置消息的属性
```
DefaultMQProducer producer = new DefaultMQProducer("please_rename_unique_group_name");
producer.start();
Message msg = new Message("TopicTest",
tag,
("Hello RocketMQ " + i).getBytes(RemotingHelper.DEFAULT_CHARSET)
);
// 设置一些属性
msg.putUserProperty("a", String.valueOf(i));
SendResult sendResult = producer.send(msg);
producer.shutdown();
```
### 3.5.3 消息消费者
用MessageSelector.bySql来使用sql筛选消息
```
DefaultMQPushConsumer consumer = new DefaultMQPushConsumer("please_rename_unique_group_name_4");
// 只有订阅的消息有这个属性a, a >=0 and a <= 3
consumer.subscribe("TopicTest", MessageSelector.bySql("a between 0 and 3");
consumer.registerMessageListener(new MessageListenerConcurrently() {
@Override
public ConsumeConcurrentlyStatus consumeMessage(List<MessageExt> msgs, ConsumeConcurrentlyContext context) {
return ConsumeConcurrentlyStatus.CONSUME_SUCCESS;
}
});
consumer.start();
```
3.6 事务消息
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
### 3.6.1 流程分析
上图说明了事务消息的大致方案，其中分为两个流程：正常事务消息的发送及提交、事务消息的补偿流程。
#### 1）事务消息发送及提交
(1) 发送消息（half消息）。
(2) 服务端响应消息写入结果。
(3) 根据发送结果执行本地事务（如果写入失败，此时half消息对业务不可见，本地逻辑不执行）。
(4) 根据本地事务状态执行Commit或者Rollback（Commit操作生成消息索引，消息对消费者可见）
#### 2）事务补偿
(5) 对没有Commit/Rollback的事务消息（pending状态的消息），从服务端发起一次“回查”
(6) Producer收到回查消息，检查回查消息对应的本地事务的状态
(7) 根据本地事务状态，重新Commit或者Rollback
其中，补偿阶段用于解决消息Commit或者Rollback发生超时或者失败的情况。
#### 3）事务消息状态
事务消息共有三种状态，提交状态、回滚状态、中间状态：
* TransactionStatus.CommitTransaction：提交事务，它允许消费者消费此消息。
* TransactionStatus.RollbackTransaction：回滚事务，它代表该消息将被删除，不允许被消费。
* TransactionStatus.Unknown：中间状态，它代表需要检查消息队列来确定状态。
### 3.6.2 发送事务消息
#### 1) 创建事务性生产者
使用 `TransactionMQProducer`类创建生产者，并指定唯一的 `ProducerGroup`，就可以设置自定义线程池来处理这些检查请求。执行本地事务后、需要根据执行结果对消息队列进行回复。回传的事务状态在请参考前一节。
```
public class Producer {
public static void main(String[] args) throws MQClientException, InterruptedException {
//创建事务监听器
TransactionListener transactionListener = new TransactionListenerImpl();
//创建消息生产者
TransactionMQProducer producer = new TransactionMQProducer("group6");
producer.setNamesrvAddr("192.168.25.135:9876;192.168.25.138:9876");
//生产者这是监听器
producer.setTransactionListener(transactionListener);
//启动消息生产者
producer.start();
String[] tags = new String[]{"TagA", "TagB", "TagC"};
for (int i = 0; i < 3; i++) {
try {
Message msg = new Message("TransactionTopic", tags[i % tags.length], "KEY" + i,
("Hello RocketMQ " + i).getBytes(RemotingHelper.DEFAULT_CHARSET));
SendResult sendResult = producer.sendMessageInTransaction(msg, null);
System.out.printf("%s%n", sendResult);
TimeUnit.SECONDS.sleep(1);
} catch (MQClientException | UnsupportedEncodingException e) {
e.printStackTrace();
}
}
//producer.shutdown();
}
}
```
#### 2）实现事务的监听接口
当发送半消息成功时，我们使用 `executeLocalTransaction` 方法来执行本地事务。它返回前一节中提到的三个事务状态之一。`checkLocalTranscation` 方法用于检查本地事务状态，并回应消息队列的检查请求。它也是返回前一节中提到的三个事务状态之一。
```
public class TransactionListenerImpl implements TransactionListener {
@Override
public LocalTransactionState executeLocalTransaction(Message msg, Object arg) {
System.out.println("执行本地事务");
if (StringUtils.equals("TagA", msg.getTags())) {
return LocalTransactionState.COMMIT_MESSAGE;
} else if (StringUtils.equals("TagB", msg.getTags())) {
return LocalTransactionState.ROLLBACK_MESSAGE;
} else {
return LocalTransactionState.UNKNOW;
}
}
@Override
public LocalTransactionState checkLocalTransaction(MessageExt msg) {
System.out.println("MQ检查消息Tag【"+msg.getTags()+"】的本地事务执行结果");
return LocalTransactionState.COMMIT_MESSAGE;
}
}
```
### 3.6.3 使用限制
1. 事务消息不支持延时消息和批量消息。
2. 为了避免单个消息被检查太多次而导致半队列消息累积，我们默认将单个消息的检查次数限制为 15 次，但是用户可以通过 Broker 配置文件的 `transactionCheckMax` 参数来修改此限制。如果已经检查某条消息超过 N 次的话（ N = `transactionCheckMax` ） 则 Broker 将丢弃此消息，并在默认情况下同时打印错误日志。用户可以通过重写 `AbstractTransactionCheckListener` 类来修改这个行为。
3. 事务消息将在 Broker 配置文件中的参数 transactionMsgTimeout 这样的特定时间长度之后被检查。当发送事务消息时，用户还可以通过设置用户属性 `CHECK_IMMUNITY_TIME_IN_SECONDS` 来改变这个限制，该参数优先于 `transactionMsgTimeout` 参数。
4. 事务性消息可能不止一次被检查或消费。
5. 提交给用户的目标主题消息可能会失败，目前这依日志的记录而定。它的高可用性通过 `RocketMQ` 本身的高可用性机制来保证，如果希望确保事务消息不丢失、并且事务完整性得到保证，建议使用同步的双重写入机制。
6. 事务消息的生产者 ID 不能与其他类型消息的生产者 ID 共享。与其他类型的消息不同，事务消息允许反向查询、MQ服务器能通过它们的生产者 ID 查询到消费者。
3.7 连接阿里云RocketMQ时配置AK与Secret
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
如果是调用阿里云的 `RocketMQ`，则还需要指定 `AK` 与 `Secret`。阿里云 Demo：[戳这里](https://code.aliyun.com/aliware_rocketmq/rocketmq-demo/tree/master?spm=a2c4g.11186623.2.7.304db1a5SquN6G)
### 3.7.1 生产者
生产者设置 `AK` 与 `Secert` 操作都一样，只需要在创建 `Producer` 时指定就行，这里就以发送普通消息为例：
```
public class SyncAKProducer {
private static RPCHook getAclRPCHook() {
return new AclClientRPCHook(new SessionCredentials("设置自己的ACCESS_KEY", "设置自己的SECRET_KEY"));
}
public static void main(String[] args) throws Exception {
/**
* 创建Producer，并开启消息轨迹
* 如果不想开启消息轨迹，可以按照如下方式创建：
* DefaultMQProducer producer = new DefaultMQProducer(M"设置自己的GroupName（唯一）", getAclRPCHook());
*/
DefaultMQProducer producer = new DefaultMQProducer("设置自己的GroupName（唯一）", getAclRPCHook(), true, null);
/**
* 设置使用接入方式为阿里云，在使用云上消息轨迹的时候，需要设置此项，如果不开启消息轨迹功能，则运行不设置此项.
*/
producer.setAccessChannel(AccessChannel.CLOUD);
// 设置NameServer的地址
producer.setNamesrvAddr("localhost:9876");
// 设置消息同步发送失败时的重试次数，默认为 2
producer.setRetryTimesWhenSendFailed(2);
// 设置消息发送超时时间，默认3000ms
producer.setSendMsgTimeout(3000);
// 启动Producer实例
producer.start();
for (int i = 0; i < 100; i++) {
// 创建消息，并指定Topic，Tag和消息体
Message msg = new Message("TopicTest" /* Topic */,
"TagA" /* Tag */,
("Hello RocketMQ " + i).getBytes(RemotingHelper.DEFAULT_CHARSET) /* Message body */
);
// 发送消息到一个Broker
SendResult sendResult = producer.send(msg);
// 通过sendResult返回消息是否成功送达
System.out.printf("%s%n", sendResult);
}
// 如果不再发送消息，关闭Producer实例。
producer.shutdown();
}
}
```
### 3.7.2 消费者
消费者设置 `AK` 与 `Secert` 的操作都一样，只需要在创建 `Consummer` 时指定就行，这里就以接收普通消息为例：
```
private static RPCHook getAclRPCHook() {
return new AclClientRPCHook(new SessionCredentials("设置自己的ACCESS_KEY", "设置自己的SECRET_KEY"));
}
public static void main(String[] args) throws Exception {
/**
* 创建Consumer，并开启消息轨迹
* 如果不想开启消息轨迹，可以按照如下方式创建：
* DefaultMQPushConsumer consumer = new DefaultMQPushConsumer(MqConfig.GROUP_ID, getAclRPCHook(), null);
*/
DefaultMQPushConsumer consumer = new DefaultMQPushConsumer("group1", getAclRPCHook(), new AllocateMessageQueueAveragely(), true, null);
/**
* 设置使用接入方式为阿里云，在使用云上消息轨迹的时候，需要设置此项，如果不开启消息轨迹功能，则运行不设置此项.
*/
consumer.setAccessChannel(AccessChannel.CLOUD);
// 指定Namesrv地址信息.
consumer.setNamesrvAddr("localhost:9876");
// 订阅Topic
consumer.subscribe("Test", "*");
//负载均衡模式消费
consumer.setMessageModel(MessageModel.CLUSTERING);
// 注册回调函数，处理消息
consumer.registerMessageListener(new MessageListenerConcurrently() {
@Override
public ConsumeConcurrentlyStatus consumeMessage(List<MessageExt> msgs,
ConsumeConcurrentlyContext context) {
System.out.printf("%s Receive New Messages: %s %n",
Thread.currentThread().getName(), msgs);
return ConsumeConcurrentlyStatus.CONSUME_SUCCESS;
}
});
//启动消息者
consumer.start();
System.out.printf("Consumer Started.%n");
}
```
四、消息发送与消费示例（Spring Boot）
=======================================================================================================================================================================================================================================================================================================================================================================================================================================================================
4.1 导入依赖
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
```
<dependency>
<groupId>org.apache.rocketmq</groupId>
<artifactId>rocketmq-spring-boot-starter</artifactId>
<version>2.1.1</version>
</dependency>
```
4.2 生产者
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
### 4.2.1 application.yaml 配置文件
```
# application.yaml
rocketmq:
name-server: 10.124.128.200:9876
producer:
group: test-group
# 发送同步消息失败时，重试次数，默认是 2
retry-times-when-send-failed: 2
# 发送异步消息失败时，重试次数，默认是 2
retry-times-when-send-async-failed: 2
# 发送消息超时时间，默认是 3s
send-message-timeout: 3000
# 连接阿里云RocketMQ时需要配置AK与SK
access-key:
secret-key:
```
### 4.2.2 生产者
```
@RestController
@RequestMapping("/test")
public class ProducerTest {
//自动注入
@Autowired
private RocketMQTemplate rocketMQTemplate;
@PostMapping("/sendSyncMessage")
public void sendSyncMessage(@RequestBody Map<String, Object> msgMap){
//构建消息
Message message = new Message("TopicName", "Tag", hash, JSON.toJSONBytes(msgData));
//发送同步消息
//方法1：使用与第三章相同的方法，调用 getProducer() 方法时会返回DefaultMQProducer对象，然后调用其方法第三章的一样了。
SendResult sendResult = rocketMQTemplate.getProducer().send(message);
//方法2：使用rocketMQTemplate封装的消息发送方法
// 第一个参数指定Topic与Tag，格式: `topicName:tags`
// 第二个参数，Message对象
sendResult = rocketMQTemplate.syncSend("TopicName:Tag", message);
}
}
```
4.2 消费者
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
### 4.2.1 application.yaml 配置文件
```
rocketmq:
name-server: 10.124.128.200:9876
# 下面的配置只有在用阿里云的RocketMQ时，才配置，自己搭建的不需要配置
consumer:
access-key:
secret-key:
access-channel: CLOUD
```
### 4.2.2 消费者消息监听器
```
@Slf4j
@Component
@RocketMQMessageListener(topic = "springboot-mq",
consumerGroup = "springboot-mq-consumer-1",
selectorExpression = "*")
public class Consumer implements RocketMQListener<String> {
@Override
public void onMessage(String message) {
log.info("Receive message：" + message);
//如果消费失败，则抛出RuntimeException，RocketMQ会自动重试
//可以手动抛出，也可以使用 Lombok 的 @SneakyThrows 注解来抛出 RuntimeException
throw new RuntimeException("消费失败");
}
}
```
`@RocketMQMessageListener` 注解的常用配置参数：
| 参数 | 类型 | 默认值 | 说明 |
| --- | --- | --- | --- |
| consumerGroup | String | | 消费者组 |
| topic | String | | Topic |
| selectorType | SelectorType | SelectorType.TAG | 使用TAG 或者SQL92选择消息，默认tag |
| selectorExpression | String | “\*” | 控制哪些消息可以选择 |
| consumeMode | ConsumeMode | ConsumeMode.CONCURRENTLY | 消费模式，并发接收还是顺序接收，默认并发模式 |
| messageModel | MessageModel | MessageModel.CLUSTERING | 消费模式，广播模式还是集群模式，默认集群模式 |
| consumeThreadMax | int | 64 | 最大消费线程数 |
| consumeTimeout | long | 15L | 消费超时时间（一条消息可能会阻塞使用线程的最长时间（以分钟为单位）） |
| nameServer | String | 配置文件中读取：${rocketmq.name-server:} | nameServer地址 |
| accessKey | String | 配置文件中读取：${rocketmq.consumer.access-key:} | AK |
| secretKey | String | 配置文件中读取：${rocketmq.consumer.secret-key:} | SK |
| accessChannel | String | ${rocketmq.access-channel:} | |
五、消息存储
=====================================================================================================================================================================================================================================================================================================================================================================================================================================================
分布式队列因为有高可靠性的要求，所以数据要进行持久化存储。
1. 消息生成者发送消息
2. MQ 收到消息，将消息进行持久化，在存储中新增一条记录
3. 返回 ACK 给生产者
4. MQ push 消息给对应的消费者，然后等待消费者返回 ACK
5. 如果消息消费者在指定时间内成功返回 ack，那么MQ认为消息消费成功，在存储中删除消息，即执行第6步；如果 MQ 在指定时间内没有收到 ACK，则认为消息消费失败，会尝试重新 push 消息，重复执行4、5、6步骤
6. MQ 删除消息
5.1 存储介质
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
目前业界较为常用的几款产品（RocketMQ/Kafka/RabbitMQ）均采用的是消息刷盘至所部署虚拟机/物理机的文件系统来做持久化（刷盘一般可以分为**异步刷盘**和**同步刷盘**两种模式）。
消息刷盘为消息存储提供了一种高效率、高可靠性和高性能的数据持久化方式。除非部署MQ机器本身或是本地磁盘挂了，否则一般是不会出现无法持久化的故障问题。
5.2 消息存储结构
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
`RocketMQ` 消息的存储是由 `ConsumeQueue` 和 `CommitLog` 配合完成的，消息真正的物理存储文件是 `CommitLog`，`ConsumeQueue` 是消息的逻辑队列，类似数据库的索引文件，存储的是指向物理存储的地址。每个 `Topic` 下的每个 `Message Queue` 都有一个对应的 `ConsumeQueue` 文件。
* `CommitLog`：存储消息的元数据
* `ConsumerQueue`：存储消息在 `CommitLog` 的索引
* `IndexFile`：为了消息查询提供了一种通过 `key` 或时间区间来查询消息的方法，这种通过 `IndexFile` 来查找消息的方法不影响发送与消费消息的主流程
5.3 顺序写
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
`RocketMQ` 的消息用顺序写，保证了消息存储的速度。
磁盘如果使用得当，磁盘的速度完全可以匹配上网络的数据传输速度。目前的高性能磁盘，**顺序写**速度可以达到 `600MB/s`， 超过了一般网卡的传输速度。但是磁盘**随机写**的速度只有大概 `100KB/s`，和顺序写的性能相差 6000 倍！因为有如此巨大的速度差别，好的消息队列系统会比普通的消息队列系统速度快多个数量级。
5.4 刷盘机制
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
`RocketMQ` 的消息是存储到磁盘上的，这样既能保证断电后恢复， 又可以让存储的消息量超出内存的限制。`RocketMQ` 为了提高性能，会尽可能地保证磁盘的顺序写。消息在通过 Producer 写入 RocketMQ 的时候，有两种写磁盘方式，分布式同步刷盘和异步刷盘。
### 1）同步刷盘
在返回写成功状态时，消息已经被写入磁盘。具体流程是，消息写入内存的 `PAGECACHE` 后，立刻通知刷盘线程刷盘，然后等待刷盘完成，刷盘线程执行完成后唤醒等待的线程，返回消息写成功的状态。
### 2）异步刷盘
在返回写成功状态时，消息可能只是被写入了内存的 `PAGECACHE`，写操作的返回快，吞吐量大；当内存里的消息量积累到一定程度时，统一触发写磁盘动作，快速写入。
### 3）配置
同步刷盘和异步刷盘，都是通过 `Broker` 配置文件里的 `flushDiskType` 参数设置的，把这个参数被配置成 `SYNC_FLUSH`（同步）、`ASYNC_FLUSH` （异步）中的一个。
5.5 零拷贝
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Linux 操作系统分为【**用户态**】和【**内核态**】，文件操作、网络操作需要涉及这两种形态的切换，免不了进行数据复制。
一台服务器把本机磁盘文件的内容发送到客户端，一般分为两个步骤：
1. `read`：读取本地文件内容；
2. `write`：将读取的内容通过网络发送出去。
这两个看似简单的操作，实际进行了4 次数据复制，分别是：
1. 从磁盘复制数据到内核态内存；
2. 从内核态内存复制到用户态内存；
3. 然后从用户态内存复制到网络驱动的内核态内存；
4. 最后是从网络驱动的内核态内存复制到网卡中进行传输。
通过使用 `mmap` 的方式，可以**省去向用户态的内存复制**，提高速度。这种机制在 Java 中是通过 `MappedByteBuffer` 实现的
`RocketMQ` 充分利用了上述特性，也就是所谓的“零拷贝”技术，提高消息存盘和网络发送的速度。
> 这里需要注意的是，采用 `MappedByteBuffer` 这种内存映射的方式有几个限制，其中之一是一次只能映射不超过 `1.5` 的文件至用户态的虚拟内存，这也是为何 `RocketMQ` 默认设置单个 `CommitLog` （存储消息的元数据）数据文件为 `1G` 的原因了
六、高可用性机制
=======================================================================================================================================================================================================================================================================================================================================================================================================================================================
`RocketMQ` 分布式集群是通过 `Master` 和 `Slave` 的配合达到高可用性的。
`Master` 和 `Slave` 的区别：在 `Broker` 的配置文件中，参数 brokerId 的值为0表明这个Broker是Master，大于0表明这个Broker是 Slave，同时brokerRole参数也会说明这个Broker是Master还是Slave。
Master角色的Broker支持读和写，Slave角色的Broker仅支持读，也就是 Producer只能和Master角色的Broker连接写入消息；Consumer可以连接 Master角色的Broker，也可以连接Slave角色的Broker来读取消息。
6.1 消息消费高可用
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
在Consumer的配置文件中，并不需要设置是从Master读还是从Slave 读，当Master不可用或者繁忙的时候，Consumer会被自动切换到从Slave 读。有了自动切换Consumer这种机制，当一个Master角色的机器出现故障后，Consumer仍然可以从Slave读取消息，不影响Consumer程序。这就达到了消费端的高可用性。
6.2 消息发送高可用
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
在创建Topic的时候，把Topic的多个Message Queue创建在多个Broker组上（相同Broker名称，不同 brokerId的机器组成一个Broker组），这样当一个Broker组的Master不可 用后，其他组的Master仍然可用，Producer仍然可以发送消息。 RocketMQ目前还不支持把Slave自动转成Master，如果机器资源不足， 需要把Slave转成Master，则要手动停止Slave角色的Broker，更改配置文 件，用新的配置文件启动Broker。
6.3 主从复制
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
如果一个 Broker 组有 Master 和 Slave，消息需要从 Master 复制到 Slave 上，有同步和异步两种复制方式。
### 1）同步复制
同步复制方式是等 Master 和 Slave 均写 成功后才反馈给客户端写成功状态；
在同步复制方式下，如果 Master 出故障， Slave 上有全部的备份数据，容易恢复，但是同步复制会增大数据写入 延迟，降低系统吞吐量。
### 2）异步复制
异步复制方式是只要 Master 写成功 即可反馈给客户端写成功状态。
在异步复制方式下，系统拥有较低的延迟和较高的吞吐量，但是如果 Master 出了故障，有些数据因为没有被写入 Slave，有可能会丢失；
### 3）配置
同步复制和异步复制是通过 Broker 配置文件里的 `brokerRole` 参数进行设置的，这个参数的值有：
* `ASYNC_MASTER`：异步复制主节点
* `SYNC_MASTER`：同步复制主节点
* `SLAVE`：从节点
### 4）总结
实际应用中要结合业务场景，合理设置**刷盘方式**和**主从复制**方式， 尤其是 `SYNC_FLUSH` （同步刷盘）方式，由于频繁地触发磁盘写动作，会明显降低性能。
通常情况下，应该把 `Master` 和 `Slave` 配置成 `ASYNC_FLUSH` （**异步刷盘**）的刷盘方式，主从之间配置成 `SYNC_MASTER` （**同步复制**）的复制方式，这样即使有一台机器出故障，仍然能保证数据不丢，是个不错的选择。
七、负载均衡
=====================================================================================================================================================================================================================================================================================================================================================================================================================================================
7.1 Producer负载均衡
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Producer 端，每个实例在发消息的时候，默认会轮询所有的 message queue 发送，以达到让消息平均落在不同的 `queue` 上。而由于 `queue` 可以散落在不同的 `broker`，所以消息就发送到不同的 `broker` 下，如下图：
图中箭头线条上的标号代表顺序，发布方会把第一条消息发送至 Queue 0，然后第二条消息发送至 Queue 1，以此类推。
7.2 Consumer负载均衡
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
### 1）集群模式
在集群消费模式下，每个订阅这个 `topic` 的**消费者组**都会收到消息，每条消息只会被一个**消费者组**中的一个实例消费。RocketMQ 采用主动拉取的方式拉取并消费消息，在拉取的时候需要明确指定拉取哪一条 message queue。
而每当实例的数量有变更，都会触发一次所有实例的负载均衡，这时候会按照 queue 的数量和实例的数量平均分配 queue 给每个实例。
默认的分配算法是 `AllocateMessageQueueAveragely`，如下图：
还有另外一种平均的算法是 `AllocateMessageQueueAveragelyByCircle`，也是平均分摊每一条 queue，只是以环状轮流分 queue 的形式，如下图：
需要注意的是，集群模式下，queue 都是只允许分配只一个实例，这是由于如果多个实例同时消费一个 queue 的消息，由于拉取哪些消息是 consumer 主动控制的，那样会导致同一个消息在不同的实例下被消费多次，所以算法上都是一个 queue 只分给一个 consumer 实例，一个 consumer 实例可以允许同时分到不同的 queue。
通过增加 `consumer` 实例去分摊 `queue` 的消费，可以起到水平扩展的消费能力的作用。而有实例下线的时候，会重新触发负载均衡，这时候原来分配到的 `queue` 将分配到其他实例上继续消费。
但是如果 `consumer` 实例的数量比 `message queue` 的总数量还多的话，多出来的 `consumer` 实例将无法分到 `queue`，也就无法消费到消息，也就无法起到分摊负载的作用了。所以需要控制让 queue 的总数量大于等于 consumer 的数量。
### 2）广播模式
由于广播模式下要求一条消息需要投递到一个消费组下面所有的消费者实例，所以也就没有消息被分摊消费的说法。
在实现上，其中一个不同就是在 consumer 分配 queue 的时候，所有 consumer 都分到所有的 queue。
八、消息重试
=====================================================================================================================================================================================================================================================================================================================================================================================================================================================
8.1 顺序消息的重试
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
对于顺序消息，当消费者消费消息失败后，消息队列 RocketMQ 会自动不断进行消息重试（每次间隔时间为 1 秒），这时，应用会出现消息消费被阻塞的情况。因此，在使用顺序消息时，务必保证应用能够及时监控并处理消费失败的情况，避免阻塞现象的发生。
8.2 无序消息的重试
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
对于无序消息（普通、定时、延时、事务消息），当消费者消费消息失败时，您可以通过设置返回状态达到消息重试的结果。
无序消息的重试只针对集群消费方式生效；广播方式不提供失败重试特性，即消费失败后，失败消息不再重试，继续消费新的消息。
### 1）重试次数
消息队列 RocketMQ 默认允许每条消息最多重试 16 次，每次重试的间隔时间如下：
| 第几次重试 | 与上次重试的间隔时间 | 第几次重试 | 与上次重试的间隔时间 |
| :-: | :-: | :-: | :-: |
| 1 | 10 秒 | 9 | 7 分钟 |
| 2 | 30 秒 | 10 | 8 分钟 |
| 3 | 1 分钟 | 11 | 9 分钟 |
| 4 | 2 分钟 | 12 | 10 分钟 |
| 5 | 3 分钟 | 13 | 20 分钟 |
| 6 | 4 分钟 | 14 | 30 分钟 |
| 7 | 5 分钟 | 15 | 1 小时 |
| 8 | 6 分钟 | 16 | 2 小时 |
如果消息重试 16 次后仍然失败，消息将不再投递。如果严格按照上述重试时间间隔计算，某条消息在一直消费失败的前提下，将会在接下来的 4 小时 46 分钟之内进行 16 次重试，超过这个时间范围消息将不再重试投递。
**注意：** 一条消息无论重试多少次，这些重试消息的 Message ID 不会改变。
### 2）配置方式
#### 消费失败后，重试配置方式
集群消费方式下，消息消费失败后期望消息重试，需要在消息监听器接口的实现中明确进行配置（三种方式任选一种）：
* 返回 `Action.ReconsumeLater` （推荐）
* 返回 Null
* 抛出异常
```
public class MessageListenerImpl implements MessageListener {
@Override
public Action consume(Message message, ConsumeContext context) {
//处理消息
doConsumeMessage(message);
//方式1：返回 Action.ReconsumeLater，消息将重试
return Action.ReconsumeLater;
//方式2：返回 null，消息将重试
return null;
//方式3：直接抛出异常， 消息将重试
throw new RuntimeException("Consumer Message exceotion");
}
}
```
#### 消费失败后，不重试配置方式
集群消费方式下，消息失败后期望消息不重试，需要捕获消费逻辑中可能抛出的异常，最终返回 `Action.CommitMessage`，此后这条消息将不会再重试。
```
public class MessageListenerImpl implements MessageListener {
@Override
public Action consume(Message message, ConsumeContext context) {
try {
doConsumeMessage(message);
} catch (Throwable e) {
//捕获消费逻辑中的所有异常，并返回 Action.CommitMessage;
return Action.CommitMessage;
}
//消息处理正常，直接返回 Action.CommitMessage;
return Action.CommitMessage;
}
}
```
#### 自定义消息最大重试次数
消息队列 RocketMQ 允许 Consumer 启动的时候设置最大重试次数，重试时间间隔将按照如下策略：
* 最大重试次数小于等于 16 次，则重试时间间隔同上表描述。
* 最大重试次数大于 16 次，超过 16 次的重试时间间隔均为每次 2 小时。
```
Properties properties = new Properties();
//配置对应 Group ID 的最大消息重试次数为 20 次
properties.put(PropertyKeyConst.MaxReconsumeTimes,"20");
Consumer consumer =ONSFactory.createConsumer(properties);
```
> 注意：
>
> * 消息最大重试次数的设置对相同 Group ID 下的所有 Consumer 实例有效。
> * 如果只对相同 Group ID 下两个 Consumer 实例中的其中一个设置了 MaxReconsumeTimes，那么该配置对两个 Consumer 实例均生效。
> * 配置采用覆盖的方式生效，即最后启动的 Consumer 实例会覆盖之前的启动实例的配置
#### 获取消息重试次数
消费者收到消息后，可按照如下方式获取消息的重试次数：
```
public class MessageListenerImpl implements MessageListener {
@Override
public Action consume(Message message, ConsumeContext context) {
//获取消息的重试次数
System.out.println(message.getReconsumeTimes());
return Action.CommitMessage;
}
}
```
### 3）多消费组重试
假设有 A 消费者组和 B 消费者组，当 A 和 B 同时监听同一个 `topic` 时，A 和 B 都获得了同一消息，但是 A 消费失败了（`return Action.ReconsumeLater`），B 却消费成功了。然后重试的时候，`rocketMQ` 只会把该消息再发送给 A 消费者组，不会再发送给 B 消费者组了。
九、死信队列
=====================================================================================================================================================================================================================================================================================================================================================================================================================================================
当一条消息初次消费失败，消息队列 RocketMQ 会自动进行消息重试；达到最大重试次数后，若消费依然失败，则表明消费者在正常情况下无法正确地消费该消息，此时，消息队列 RocketMQ 不会立刻将消息丢弃，而是将其发送到该消费者对应的特殊队列中。
在消息队列 RocketMQ 中，这种正常情况下无法被消费的消息称为死信消息（Dead-Letter Message），存储死信消息的特殊队列称为死信队列（Dead-Letter Queue）。
9.1 死信特性
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
**死信消息**具有以下特性：
* 不会再被消费者正常消费。
* 有效期与正常消息相同，均为 3 天，3 天后会被自动删除。因此，请在死信消息产生后的 3 天内及时处理。
**死信队列**具有以下特性：
* 一个死信队列对应一个 Group ID， 而不是对应单个消费者实例。
* 如果一个 Group ID 未产生死信消息，消息队列 RocketMQ 不会为其创建相应的死信队列。
* 一个死信队列包含了对应 Group ID 产生的所有死信消息，不论该消息属于哪个 Topic。
9.2 查看死信信息
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
1. 在控制台查询出现死信队列的主题信息
2. 在消息界面根据主题查询死信消息
3. 选择重新发送消息
一条消息进入死信队列，意味着某些因素导致消费者无法正常消费该消息，因此，通常需要您对其进行特殊处理。排查可疑因素并解决问题后，可以在消息队列 RocketMQ 控制台重新发送该消息，让消费者重新消费一次。
十、消费幂等
=====================================================================================================================================================================================================================================================================================================================================================================================================================================================
消息队列 RocketMQ 消费者在接收到消息以后，有必要根据业务上的唯一 Key 对消息做幂等处理的必要性。
10.1 消费幂等的必要性
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
在互联网应用中，尤其在网络不稳定的情况下，消息队列 RocketMQ 的消息有可能会出现重复，这个重复简单可以概括为以下情况：
* 发送时消息重复
当一条消息已被成功发送到服务端并完成持久化，此时出现了网络闪断或者客户端宕机，导致服务端对客户端应答失败。 如果此时生产者意识到消息发送失败并尝试再次发送消息，消费者后续会收到两条内容相同并且 Message ID 也相同的消息。
* 投递时消息重复
消息消费的场景下，消息已投递到消费者并完成业务处理，当客户端给服务端反馈应答的时候网络闪断。 为了保证消息至少被消费一次，消息队列 RocketMQ 的服务端将在网络恢复后再次尝试投递之前已被处理过的消息，消费者后续会收到两条内容相同并且 Message ID 也相同的消息。
* 负载均衡时消息重复（包括但不限于网络抖动、Broker 重启以及订阅方应用重启）
当消息队列 RocketMQ 的 Broker 或客户端重启、扩容或缩容时，会触发 Rebalance，此时消费者可能会收到重复消息。
10.2 处理方式
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
因为 Message ID 有可能出现冲突（重复）的情况，所以真正安全的幂等处理，不建议以 Message ID 作为处理依据。 最好的方式是以业务唯一标识作为幂等处理的关键依据，而业务的唯一标识可以通过消息 Key 进行设置：
```
Message message = new Message();
message.setKey("ORDERID_100");
SendResult sendResult = producer.send(message);
```
订阅方收到消息时可以根据消息的 Key 进行幂等处理：
```
consumer.subscribe("ons_test", "*", new MessageListener() {
public Action consume(Message message, ConsumeContext context) {
String key = message.getKey()
// 根据业务唯一标识的 key 做幂等处理
}
});
```
十一、RocketMQ使用注意事项
================================================================================================================================================================================================================================================================================================================================================================================================================================================================
1. 同一消费者组下，**消费者逻辑应相同**（监听的 `topic`，`tag` 都要相同）
2. 默认配置下，不同消费者组之间是消息共享（所有消费者组都能获取到同一消息），消费者组内的消费者是负载均衡（只有一个消费者会获得消息）
声明：本网站发布的内容（图片、视频和文字）以原创、转载和分享网络内容为主，如果涉及侵权请尽快告知，我们将会在第一时间删除。文章观点不代表本网站立场，如需处理请联系客服。微信：ZDVIP51888；邮箱：8122356@qq.com。
本文为博主原创文章，遵循CC 4.0 BY-SA版权协议,转载请附上原文出处链接和本声明，转载时需注明出处: 内容转载自: 智编生态圈👉https://www.atutil.com/article/24
本文为博主原创文章，遵循CC 4.0 BY-SA版权协议,转载请附上原文出处链接和本声明，转载时需注明出处: 内容转载自: 智编生态圈👉https://www.atutil.com/article/24
AtUtil
