一、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
下载地址:下载地址
官方文档:rocketmq.apache.org/docs/quick-…
2.2.2 环境要求
- Linux64位系统
- JDK1.8(64位)
2.2 安装RocketMQ
2.2.1 安装步骤
我这里是以二进制包方式来安装的:
- 解压安装包
- 进入安装目录
2.2.2 目录介绍
bin
:启动脚本,包括 shell 脚本和 CMD 脚本conf
:实例配置文件 ,包括 broker 配置文件、logback 配置文件等lib
:依赖 jar 包,包括Netty、commons-lang、FastJSON等
2.3 启动RocketMQ
RocketMQ
默认的虚拟机内存较大,启动Broker
或者NameServer
可能会因为内存不足而导致失败,所以需要编辑如下两个配置文件,修改 JVM 内存大小
1 | shell复制代码# 编辑 runbroker.sh 和 runserver.sh 修改默认 JVM 大小 |
- 启动
NameServer
1 | shell复制代码# 1.启动NameServer |
- 启动
Broker
1 | shell复制代码# 1.启动Broker |
bin/mqbroker
的一些可选参数:
-c
:指定配置文件路径-n
:NameServer 的地址
2.4 测试RocketMQ
2.4.1 发送消息
1 | shell复制代码# 1.设置环境变量 |
2.4.2 接收消息
1 | shell复制代码# 1.设置环境变量 |
2.5 关闭RocketMQ
1 | shell复制代码# 1.关闭NameServer |
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
1 | py复制代码#所属集群名字 |
2.8 可视化监控平台搭建
2.8.1 概述
RocketMQ
有一个对其扩展的开源项目 incubator-rocketmq-externals,这个项目中有一个子模块叫 rocketmq-console
,这个便是管理控制台项目了,先将 incubator-rocketmq-externals 拉到本地,因为我们需要自己对 rocketmq-console
进行编译打包运行。
2.8.2 下载并编译打包
- 克隆项目
1 | bash复制代码git clone https://github.com/apache/rocketmq-externals |
- 在
rocketmq-console
中配置namesrv
集群地址:
1 | bash复制代码$ cd rocketmq-console |
- 配置完成进行编译并打包
1 | shell复制代码mvn clean package -Dmaven.test.skip=true |
- 启动 rocketmq-console:
1 | shell复制代码nohup java -jar rocketmq-console-ng-2.0.0.jar > tmp.log & |
启动成功后,我们就可以通过浏览器访问 http://IP地址:8080
进入控制台界面了,如下图:
三、消息发送与消费示例(Maven)
- 导入MQ客户端依赖
==注意==:rocketmq-client
的版本,要与 RocketMQ
的版本一致
1 | xml复制代码<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)发送同步消息
这种可靠性同步地发送方式使用的比较广泛,比如:重要的消息通知,短信通知。
1 | java复制代码public class SyncProducer { |
2)发送异步消息
异步消息通常用在对响应时间敏感的业务场景,即发送端不能容忍长时间地等待Broker的响应。
1 | java复制代码public class AsyncProducer { |
3)单向发送消息
这种方式主要用在不特别关心发送结果的场景,例如日志发送。
1 | java复制代码public class OnewayProducer { |
3.1.2 消费消息
1)集群模式(负载均衡)
消费者采用集群方式消费消息,==一条消息同一个消费者组中只有一个消费者会消费到==
1 | java复制代码public static void main(String[] args) throws Exception { |
2)广播模式
消费者采用广播的方式消费消息,==一条消息同一个消费者组中每个消费者都要消费==
1 | java复制代码public static void main(String[] args) throws Exception { |
3.2 顺序消息
消息有序指的是可以按照消息的发送顺序来消费(FIFO)。RocketMQ可以严格的保证消息有序,可以分为分区有序或者全局有序。
顺序消费的原理解析,在默认的情况下消息发送会采取Round Robin轮询方式把消息发送到不同的queue(分区队列);而消费消息的时候从多个queue上拉取消息,这种情况发送和消费是不能保证顺序。但是如果控制发送的顺序消息只依次发送到同一个queue中,消费的时候只从这个queue上依次拉取,则就保证了顺序。当发送和消费参与的queue只有一个,则是全局有序;如果多个queue参与,则为分区有序,即相对每个queue,消息都是有序的。
下面用订单进行分区有序的示例。一个订单的顺序流程是:创建、付款、推送、完成。订单号相同的消息会被先后发送到同一个队列中,消费时,同一个OrderId获取到的肯定是同一个队列。
3.2.1 顺序消息生产
1 | java复制代码/** |
3.2.2 顺序消费消息
1 | java复制代码/** |
3.3 延时消息
比如电商里,提交了一个订单就可以发送一个延时消息,1h后去检查这个订单的状态,如果还是未付款就取消订单释放库存。
3.3.1 启动消息消费者
1 | java复制代码public class ScheduledMessageConsumer { |
3.3.2 发送延时消息
1 | java复制代码public class ScheduledMessageProducer { |
###4.3.3 验证
您将会看到消息的消费比存储时间晚10秒
3.3.4 使用限制
1 | java复制代码// org/apache/rocketmq/store/config/MessageStoreConfig.java |
现在RocketMq并不支持任意时间的延时,需要设置几个固定的延时等级,从1s到2h分别对应着等级1到18
3.4 批量消息
批量发送消息能显著提高传递小消息的性能。限制是这些批量消息应该有相同的topic,相同的waitStoreMsgOK,而且不能是延时消息。此外,这一批消息的总大小不应超过4MB。
3.4.1 发送批量消息
如果您每次只发送不超过 4MB
的消息,则很容易使用批处理,样例如下:
1 | java复制代码String topic = "BatchTest"; |
如果消息的总长度可能大于 4MB
时,这时候最好把消息进行分割
1 | java复制代码public class ListSplitter implements Iterator<List<Message>> { |
3.5 过滤消息
在大多数情况下,TAG是一个简单而有用的设计,其可以来选择您想要的消息。例如:
1 | java复制代码DefaultMQPushConsumer consumer = new DefaultMQPushConsumer("CID_EXAMPLE"); |
消费者将接收包含TAGA或TAGB或TAGC的消息。但是限制是一个消息只能有一个标签,这对于复杂的场景可能不起作用。在这种情况下,可以使用SQL表达式筛选消息。SQL特性可以通过发送消息时的属性来进行计算。在RocketMQ定义的语法下,可以实现一些简单的逻辑。下面是一个例子:
1 | te复制代码------------ |
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语句,接口如下:
1 | java复制代码public void subscribe(finalString topic, final MessageSelector messageSelector) |
3.5.2 消息生产者
发送消息时,你能通过putUserProperty
来设置消息的属性
1 | java复制代码DefaultMQProducer producer = new DefaultMQProducer("please_rename_unique_group_name"); |
3.5.3 消息消费者
用MessageSelector.bySql来使用sql筛选消息
1 | java复制代码DefaultMQPushConsumer consumer = new DefaultMQPushConsumer("please_rename_unique_group_name_4"); |
3.6 事务消息
3.6.1 流程分析
上图说明了事务消息的大致方案,其中分为两个流程:正常事务消息的发送及提交、事务消息的补偿流程。
####1)事务消息发送及提交
(1) 发送消息(half消息)。
(2) 服务端响应消息写入结果。
(3) 根据发送结果执行本地事务(如果写入失败,此时half消息对业务不可见,本地逻辑不执行)。
(4) 根据本地事务状态执行Commit或者Rollback(Commit操作生成消息索引,消息对消费者可见)
2)事务补偿
(1) 对没有Commit/Rollback的事务消息(pending状态的消息),从服务端发起一次“回查”
(2) Producer收到回查消息,检查回查消息对应的本地事务的状态
(3) 根据本地事务状态,重新Commit或者Rollback
其中,补偿阶段用于解决消息Commit或者Rollback发生超时或者失败的情况。
3)事务消息状态
事务消息共有三种状态,提交状态、回滚状态、中间状态:
- TransactionStatus.CommitTransaction: 提交事务,它允许消费者消费此消息。
- TransactionStatus.RollbackTransaction: 回滚事务,它代表该消息将被删除,不允许被消费。
- TransactionStatus.Unknown: 中间状态,它代表需要检查消息队列来确定状态。
3.6.2 发送事务消息
1) 创建事务性生产者
使用 TransactionMQProducer
类创建生产者,并指定唯一的 ProducerGroup
,就可以设置自定义线程池来处理这些检查请求。执行本地事务后、需要根据执行结果对消息队列进行回复。回传的事务状态在请参考前一节。
1 | java复制代码public class Producer { |
2)实现事务的监听接口
当发送半消息成功时,我们使用 executeLocalTransaction
方法来执行本地事务。它返回前一节中提到的三个事务状态之一。checkLocalTranscation
方法用于检查本地事务状态,并回应消息队列的检查请求。它也是返回前一节中提到的三个事务状态之一。
1 | java复制代码public class TransactionListenerImpl implements TransactionListener { |
3.6.3 使用限制
- 事务消息不支持延时消息和批量消息。
- 为了避免单个消息被检查太多次而导致半队列消息累积,我们默认将单个消息的检查次数限制为 15 次,但是用户可以通过 Broker 配置文件的
transactionCheckMax
参数来修改此限制。如果已经检查某条消息超过 N 次的话( N =transactionCheckMax
) 则 Broker 将丢弃此消息,并在默认情况下同时打印错误日志。用户可以通过重写AbstractTransactionCheckListener
类来修改这个行为。 - 事务消息将在 Broker 配置文件中的参数 transactionMsgTimeout 这样的特定时间长度之后被检查。当发送事务消息时,用户还可以通过设置用户属性
CHECK_IMMUNITY_TIME_IN_SECONDS
来改变这个限制,该参数优先于transactionMsgTimeout
参数。 - 事务性消息可能不止一次被检查或消费。
- 提交给用户的目标主题消息可能会失败,目前这依日志的记录而定。它的高可用性通过
RocketMQ
本身的高可用性机制来保证,如果希望确保事务消息不丢失、并且事务完整性得到保证,建议使用同步的双重写入机制。 - 事务消息的生产者 ID 不能与其他类型消息的生产者 ID 共享。与其他类型的消息不同,事务消息允许反向查询、MQ服务器能通过它们的生产者 ID 查询到消费者。
3.7 连接阿里云RocketMQ时配置AK与Secret
如果是调用阿里云的 RocketMQ
,则还需要指定 AK
与 Secret
。阿里云 Demo:戳这里
3.7.1 生产者
生产者设置 AK
与 Secert
操作都一样,只需要在创建 Producer
时指定就行,这里就以发送普通消息为例:
1 | java复制代码public class SyncAKProducer { |
3.7.2 消费者
消费者设置 AK
与 Secert
的操作都一样,只需要在创建 Consummer
时指定就行,这里就以接收普通消息为例:
1 | java复制代码private static RPCHook getAclRPCHook() { |
四、消息发送与消费示例(Spring Boot)
4.1 导入依赖
1 | xml复制代码 <dependency> |
4.2 生产者
4.2.1 application.yaml 配置文件
1 | yaml复制代码# application.yaml |
4.2.2 生产者
1 | java复制代码@RestController |
4.2 消费者
4.2.1 application.yaml 配置文件
1 | yaml复制代码rocketmq: |
4.2.2 消费者消息监听器
1 | java复制代码@Slf4j |
@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:} |
五、消息存储
分布式队列因为有高可靠性的要求,所以数据要进行持久化存储。
- 消息生成者发送消息
- MQ 收到消息,将消息进行持久化,在存储中新增一条记录
- 返回 ACK 给生产者
- MQ push 消息给对应的消费者,然后等待消费者返回 ACK
- 如果消息消费者在指定时间内成功返回 ack,那么MQ认为消息消费成功,在存储中删除消息,即执行第6步;如果 MQ 在指定时间内没有收到 ACK,则认为消息消费失败,会尝试重新 push 消息,重复执行4、5、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 操作系统分为【用户态】和【内核态】,文件操作、网络操作需要涉及这两种形态的切换,免不了进行数据复制。
一台服务器把本机磁盘文件的内容发送到客户端,一般分为两个步骤:
read
:读取本地文件内容;write
:将读取的内容通过网络发送出去。
这两个看似简单的操作,实际进行了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
- 抛出异常
1 | java复制代码public class MessageListenerImpl implements MessageListener { |
消费失败后,不重试配置方式
集群消费方式下,消息失败后期望消息不重试,需要捕获消费逻辑中可能抛出的异常,最终返回 Action.CommitMessage
,此后这条消息将不会再重试。
1 | java复制代码public class MessageListenerImpl implements MessageListener { |
自定义消息最大重试次数
消息队列 RocketMQ 允许 Consumer 启动的时候设置最大重试次数,重试时间间隔将按照如下策略:
- 最大重试次数小于等于 16 次,则重试时间间隔同上表描述。
- 最大重试次数大于 16 次,超过 16 次的重试时间间隔均为每次 2 小时。
1 | java复制代码Properties properties = new Properties(); |
注意:
- 消息最大重试次数的设置对相同 Group ID 下的所有 Consumer 实例有效。
- 如果只对相同 Group ID 下两个 Consumer 实例中的其中一个设置了 MaxReconsumeTimes,那么该配置对两个 Consumer 实例均生效。
- 配置采用覆盖的方式生效,即最后启动的 Consumer 实例会覆盖之前的启动实例的配置
获取消息重试次数
消费者收到消息后,可按照如下方式获取消息的重试次数:
1 | java复制代码public class MessageListenerImpl implements MessageListener { |
3)多消费组重试
假设有 A 消费者组和 B 消费者组,当 A 和 B 同时监听同一个 topic
时,A 和 B 都获得了同一消息,但是 A 消费失败了(return Action.ReconsumeLater
),B 却消费成功了。然后重试的时候,rocketMQ
只会把该消息再发送给 B 消费者组,不会再发送给 A 消费者组了。
九、死信队列
当一条消息初次消费失败,消息队列 RocketMQ 会自动进行消息重试;达到最大重试次数后,若消费依然失败,则表明消费者在正常情况下无法正确地消费该消息,此时,消息队列 RocketMQ 不会立刻将消息丢弃,而是将其发送到该消费者对应的特殊队列中。
在消息队列 RocketMQ 中,这种正常情况下无法被消费的消息称为死信消息(Dead-Letter Message),存储死信消息的特殊队列称为死信队列(Dead-Letter Queue)。
9.1 死信特性
死信消息具有以下特性:
- 不会再被消费者正常消费。
- 有效期与正常消息相同,均为 3 天,3 天后会被自动删除。因此,请在死信消息产生后的 3 天内及时处理。
死信队列具有以下特性:
- 一个死信队列对应一个 Group ID, 而不是对应单个消费者实例。
- 如果一个 Group ID 未产生死信消息,消息队列 RocketMQ 不会为其创建相应的死信队列。
- 一个死信队列包含了对应 Group ID 产生的所有死信消息,不论该消息属于哪个 Topic。
9.2 查看死信信息
- 在控制台查询出现死信队列的主题信息
2. 在消息界面根据主题查询死信消息
3. 选择重新发送消息
一条消息进入死信队列,意味着某些因素导致消费者无法正常消费该消息,因此,通常需要您对其进行特殊处理。排查可疑因素并解决问题后,可以在消息队列 RocketMQ 控制台重新发送该消息,让消费者重新消费一次。
十、消费幂等
消息队列 RocketMQ 消费者在接收到消息以后,有必要根据业务上的唯一 Key 对消息做幂等处理的必要性。
10.1 消费幂等的必要性
在互联网应用中,尤其在网络不稳定的情况下,消息队列 RocketMQ 的消息有可能会出现重复,这个重复简单可以概括为以下情况:
- 发送时消息重复
当一条消息已被成功发送到服务端并完成持久化,此时出现了网络闪断或者客户端宕机,导致服务端对客户端应答失败。 如果此时生产者意识到消息发送失败并尝试再次发送消息,消费者后续会收到两条内容相同并且 Message ID 也相同的消息。
- 投递时消息重复
消息消费的场景下,消息已投递到消费者并完成业务处理,当客户端给服务端反馈应答的时候网络闪断。 为了保证消息至少被消费一次,消息队列 RocketMQ 的服务端将在网络恢复后再次尝试投递之前已被处理过的消息,消费者后续会收到两条内容相同并且 Message ID 也相同的消息。
- 负载均衡时消息重复(包括但不限于网络抖动、Broker 重启以及订阅方应用重启)
当消息队列 RocketMQ 的 Broker 或客户端重启、扩容或缩容时,会触发 Rebalance,此时消费者可能会收到重复消息。
10.2 处理方式
因为 Message ID 有可能出现冲突(重复)的情况,所以真正安全的幂等处理,不建议以 Message ID 作为处理依据。 最好的方式是以业务唯一标识作为幂等处理的关键依据,而业务的唯一标识可以通过消息 Key 进行设置:
1 | java复制代码Message message = new Message(); |
订阅方收到消息时可以根据消息的 Key 进行幂等处理:
1 | java复制代码consumer.subscribe("ons_test", "*", new MessageListener() { |
十一、RocketMQ使用注意事项
- 同一消费者组下,消费者逻辑应相同(监听的
topic
,tag
都要相同) - 默认配置下,不同消费者组之间是消息共享(所有消费者组都能获取到同一消息),消费者组内的消费者是负载均衡(只有一个消费者会获得消息)
本文转载自: 掘金