摘要:RocketMQ与SpringBoot集成,使用rocketmq-client依赖,使用rocketmq官方原生方式操作mq。包括基本消息(消息发送、消费),顺序消息,延时消息,批量消息,过滤消息,消息事务,Logappender 日志,OpenMessaging。
目录
[TOC]
样例代码
快速入门:基本样例
定时消息
消费重试
消费异常处理机制
广播消费
顺序消息
消息过滤
事务消息
监控端点
更多的配置项信息
接入阿里云的消息队列 RocketMQ
1 基本样例
在基本样例中我们提供如下的功能场景:
- 使用RocketMQ发送三种类型的消息:同步消息、异步消息和单向消息。其中前两种消息是可靠的,因为会有发送是否成功的应答。
- 使用RocketMQ来消费接收到的消息。
1.1 加入依赖
maven:
1 | |
gradle
1 | |
1.2 消息发送
RocketMQ Producer 一共有三种发送消息的方式。
1、发送同步消息
这种可靠性同步地发送方式使用的比较广泛,比如:重要的消息通知,短信通知。
1 | |
2、发送异步消息
异步消息:通常用在对响应时间敏感的业务场景,即发送端不能容忍长时间地等待Broker的响应。
1 | |
3、单向发送消息
这种方式主要用在不特别关心发送结果的场景,例如日志发送。
1 | |
1.3 消费消息
1 | |
2 顺序消息样例
消息有序指的是可以按照消息的发送顺序来消费(FIFO)。RocketMQ可以严格的保证消息有序,可以分为分区有序或者全局有序。
顺序消费的原理解析,在默认的情况下消息发送会采取Round Robin轮询方式把消息发送到不同的queue(分区队列);而消费消息的时候从多个queue上拉取消息,这种情况发送和消费是不能保证顺序。但是如果控制发送的顺序消息只依次发送到同一个queue中,消费的时候只从这个queue上依次拉取,则就保证了顺序。当发送和消费参与的queue只有一个,则是全局有序;如果多个queue参与,则为分区有序,即相对每个queue,消息都是有序的。
下面用订单进行分区有序的示例。一个订单的顺序流程是:创建、付款、推送、完成。订单号相同的消息会被先后发送到同一个队列中,消费时,同一个OrderId获取到的肯定是同一个队列。
2.1 顺序消息生产
1 | |
2.2 顺序消费消息
1 | |
延时、定时消息样例
定时消息,是指消息发到 Broker 后,不能立刻被 Consumer 消费,要到特定的时间点或者等待特定的时间后才能被消费。
使用场景
比如电商里,提交了一个订单就可以发送一个延时消息,1h后去检查这个订单的状态,如果还是未付款就取消订单释放库存。
启动消费者等待传入订阅消息
1 | |
发送延时消息
1 | |
延迟级别和时间精度
现在RocketMq并不支持任意时间的延时,需要设置几个固定的延时等级,从1s到2h分别对应着等级1到18 消息消费失败会进入延时消息队列。
- 消息发送时间与设置的延时等级和重试次数有关,详见代码
SendMessageProcessor.java - 如果想要任一时刻的定时消息,可以考虑借助 MySQL + Job 来实现。又或者考虑使用 DDMQ(滴滴打车基于 RocketMQ 和 Kafka 改造的开源消息队列)。
1 | |
| 延迟级别 | 时间 | 延迟级别 | 时间 | 延迟级别 | 时间 |
|---|---|---|---|---|---|
| 1 | 1s | 7 | 3m | 13 | 9m |
| 2 | 5s | 8 | 4m | 14 | 10m |
| 3 | 10s | 9 | 5m | 15 | 20m |
| 4 | 30s | 10 | 6m | 16 | 30m |
| 5 | 1m | 11 | 7m | 17 | 1h |
| 6 | 2m | 12 | 8m | 18 | 2h |
Controller
修改 Demo01Controller 类,增发送定时消息的 HTTP 接口。
1 | |
简单测试
① 执行 ConsumerApplication,启动消费者的实例。
② 执行 ProducerApplication,启动生产者的实例。
之后,请求 http://127.0.0.1:18080/demo01/send_delay 接口,发送延迟 10 秒的定时消息。
IDEA 控制台输出日志如下:
1 | |
符合预期。在 Producer 发送的消息之后,Consumer 确实 10 秒后才消费消息。
将会看到消息的消费比存储时间晚10秒。
4 批量消息样例
批量发送消息能显著提高传递小消息的性能。限制是这些批量消息应该有相同的topic,相同的waitStoreMsgOK,而且不能是延时消息。此外,这一批消息的总大小不应超过4MB。
4.1 发送批量消息
如果您每次只发送不超过4MB的消息,则很容易使用批处理,样例如下:
1 | |
4.2 消息列表分割
复杂度只有当你发送大批量时才会增长,你可能不确定它是否超过了大小限制(4MB)。这时候你最好把你的消息列表分割一下:
1 | |
5 过滤消息样例
在大多数情况下,TAG是一个简单而有用的设计,其可以来选择您想要的消息。例如:
1 | |
消费者将接收包含TAGA或TAGB或TAGC的消息。但是限制是一个消息只能有一个标签,这对于复杂的场景可能不起作用。在这种情况下,可以使用SQL表达式筛选消息。SQL特性可以通过发送消息时的属性来进行计算。在RocketMQ定义的语法下,可以实现一些简单的逻辑。下面是一个例子:
1 | |
5.1 基本语法
RocketMQ只定义了一些基本语法来支持这个特性。你也可以很容易地扩展它。
- 数值比较,比如:>,>=,<,<=,BETWEEN,=;
- 字符比较,比如:=,<>,IN;
- IS NULL 或者 IS NOT NULL;
- 逻辑符号 AND,OR,NOT;
常量支持类型为:
- 数值,比如:123,3.1415;
- 字符,比如:‘abc’,必须用单引号包裹起来;
- NULL,特殊的常量
- 布尔值,TRUE 或 FALSE
只有使用push模式的消费者才能用使用SQL92标准的sql语句,接口如下:
1 | |
5.2 使用样例
1、生产者样例
发送消息时,你能通过putUserProperty来设置消息的属性
1 | |
2、消费者样例
用MessageSelector.bySql来使用sql筛选消息
1 | |
6 消息事务样例
事务消息共有三种状态,提交状态、回滚状态、中间状态:
- TransactionStatus.CommitTransaction: 提交事务,它允许消费者消费此消息。
- TransactionStatus.RollbackTransaction: 回滚事务,它代表该消息将被删除,不允许被消费。
- TransactionStatus.Unknown: 中间状态,它代表需要检查消息队列来确定状态。
6.1 发送事务消息样例
1、创建事务性生产者
使用 TransactionMQProducer类创建生产者,并指定唯一的 ProducerGroup,就可以设置自定义线程池来处理这些检查请求。执行本地事务后、需要根据执行结果对消息队列进行回复。回传的事务状态在请参考前一节。
1 | |
2、实现事务的监听接口
当发送半消息成功时,我们使用 executeLocalTransaction 方法来执行本地事务。它返回前一节中提到的三个事务状态之一。checkLocalTransaction 方法用于检查本地事务状态,并回应消息队列的检查请求。它也是返回前一节中提到的三个事务状态之一。
1 | |
6.2 事务消息使用上的限制
- 事务消息不支持延时消息和批量消息。
- 为了避免单个消息被检查太多次而导致半队列消息累积,我们默认将单个消息的检查次数限制为 15 次,但是用户可以通过 Broker 配置文件的
transactionCheckMax参数来修改此限制。如果已经检查某条消息超过 N 次的话( N =transactionCheckMax) 则 Broker 将丢弃此消息,并在默认情况下同时打印错误日志。用户可以通过重写AbstractTransactionalMessageCheckListener类来修改这个行为。 - 事务消息将在 Broker 配置文件中的参数 transactionTimeout 这样的特定时间长度之后被检查。当发送事务消息时,用户还可以通过设置用户属性 CHECK_IMMUNITY_TIME_IN_SECONDS 来改变这个限制,该参数优先于
transactionTimeout参数。 - 事务性消息可能不止一次被检查或消费。
- 提交给用户的目标主题消息可能会失败,目前这依日志的记录而定。它的高可用性通过 RocketMQ 本身的高可用性机制来保证,如果希望确保事务消息不丢失、并且事务完整性得到保证,建议使用同步的双重写入机制。
- 事务消息的生产者 GroupName 不能与其他类型消息的生产者 GroupName 共享。与其他类型的消息不同,事务消息允许反向查询、MQ服务器能通过它们的生产者 GroupName 查询到生产者。
7 Logappender样例
RocketMQ日志提供log4j、log4j2和logback日志框架作为业务应用,下面是配置样例
7.1 log4j样例
按下面样例使用log4j属性配置
1 | |
按下面样例使用log4j xml配置来使用异步添加日志
1 | |
7.2 log4j2样例
用log4j2时,配置如下,如果想要非阻塞,只需要使用异步添加引用即可
1 | |
7.3 logback样例
1 | |
8 OpenMessaging样例
OpenMessaging旨在建立消息和流处理规范,以为金融、电子商务、物联网和大数据领域提供通用框架及工业级指导方案。在分布式异构环境中,设计原则是面向云、简单、灵活和独立于语言。符合这些规范将帮助企业方便的开发跨平台和操作系统的异构消息传递应用程序。提供了openmessaging-api 0.3.0-alpha的部分实现,下面的示例演示如何基于OpenMessaging访问RocketMQ。
8.1 OMSProducer样例
下面的示例演示如何在同步、异步或单向传输中向RocketMQ代理发送消息。
1 | |
8.2 OMSPullConsumer
用OMS PullConsumer 来从指定的队列中拉取消息
1 | |
8.3 OMSPushConsumer
以下示范如何将 OMS PushConsumer 添加到指定的队列,并通过 MessageListener 消费这些消息。
1 | |