RocketMQ之八:重试队列,死信队列,消息轨迹
问题思考
- 死信队列的应用场景?
- 死信队列中的数据是如何产生的?
- 如何查看死信队列中的数据?
- 死信队列的读写权限?
- 死信队列如何消费?
- 重试队列和死信队列的配置
- 消息轨迹
1、应用场景
一般应用在当正常业务处理时出现异常时,将消息拒绝则会进入到死信队列中,有助于统计异常数据并做后续的数据修复处理;
2、数据是如何产生的?
重试队列在重试16次(默认次数)将消息放入死信队列
参考: https://blog.csdn.net/hqwang4/article/details/99971596
3、如何查看死信队列中的数据?
通过console查看死信队列的消息,报如下异常:
org.apache.rocketmq.client.exception.MQClientException:
Can not find Message Queue for this topic, %DLQ%RetryConsumer See
http://rocketmq.apache.org/docs/faq/ for further details.
但是在broker机器上通过命令行查看topic,死信队列确实存在。
sh bin/mqadmin topiclist -n 10.200.110.46:9876;10.200.110.101:9876
4、死信队列的读写权限
4.1、查看该topic信息,发现perm为2
sh bin/mqadmin topicRoute -n 10.200.110.46:9876 -n 10.200.110.101:9876 -t %DLQ%groupnamedef2
[root@localhost rocketmq-4.5.2]# sh bin/mqadmin topicRoute -n 10.200.110.46:9876 -n 10.200.110.101:9876 -t %DLQ%groupnamedef2
RocketMQLog:WARN No appenders could be found for logger (io.netty.util.internal.PlatformDependent0).
RocketMQLog:WARN Please initialize the logger system properly.
{
"brokerDatas":[
{
"brokerAddrs":{0:"10.200.110.46:10911"
},
"brokerName":"broker-b",
"cluster":"rocketmq-cluster"
}
],
"filterServerTable":{},
"queueDatas":[
{
"brokerName":"broker-b",
"perm":2,
"readQueueNums":1,
"topicSynFlag":0,
"writeQueueNums":1
}
]
}
[root@localhost rocketmq-4.5.2]#
4.2、修改死信队列的权限
命令行方式:
第一个broker机器执行:sh mqadmin updateTopic -b 10.200.110.46:10911 -n 10.200.110.46:9876 -t %DLQ% groupnamedef2 -p 6
[root@localhost rocketmq-4.5.2]# sh bin/mqadmin updateTopic -b 10.200.110.46:10911 -n 10.200.110.46:9876 -t %DLQ% groupnamedef2 -p 6
RocketMQLog:WARN No appenders could be found for logger (io.netty.util.internal.PlatformDependent0).
RocketMQLog:WARN Please initialize the logger system properly.
create topic to 10.200.110.46:10911 success.
TopicConfig [topicName=%DLQ%, readQueueNums=8, writeQueueNums=8, perm=RW-, topicFilterType=SINGLE_TAG, topicSysFlag=0, order=false][root@localhost rocketmq-4.5.2]#
第二个broker机器执行:sh mqadmin updateTopic -b 10.200.110.48:10911 -n 10.200.110.46:9876 -t %DLQ% groupnamedef2 -p 6
[root@localhost rocketmq-4.5.2]# sh bin/mqadmin updateTopic -b 10.200.110.48:10911 -n 10.200.110.46:9876 -t %DLQ% groupnamedef2 -p 6
RocketMQLog:WARN No appenders could be found for logger (io.netty.util.internal.PlatformDependent0).
RocketMQLog:WARN Please initialize the logger system properly.
create topic to 10.200.110.48:10911 success.
TopicConfig [topicName=%DLQ%, readQueueNums=8, writeQueueNums=8, perm=RW-, topicFilterType=SINGLE_TAG, topicSysFlag=0, order=false][root@localhost rocketmq-4.5.2]#
或者在控制台中操作:
查看死信队列的权限及修改该topic为写权限
修改死信队列读写权限后,查询Message
5、死信队列如何消费
死信队列中的数据需要通过新订阅该topic进行消费。
每个topic被消费后,如果消费失败超过次数会进入重试队列、死信队列等。名称会以
- %RETRY%消费组名称
- %DLQ%消费组名称
例如:
我的普通队列是:topic-0903
消费组及消费者是:
mq.rocketmq.consumers[3].topic: topic-0903~*
mq.rocketmq.consumers[3].groupName: group0903
多次消费失败后,会生成:
如果要通过API读取死信队列的内容,即%DLQ%group0903的内容,则需要重新定义消费者:
消费死信队列%DLQ%group0903的消费者定义:
mq.rocketmq.consumers[4].topic: '%DLQ%group0903~*'
mq.rocketmq.consumers[4].groupName: groupdlq0903
mq.rocketmq.consumers[4].id: "rocketmq_consumer_dlq0903"
6、重试队列和死信队列的配置
消费端,一直不回传消费的结果。rocketmq认为消息没收到,consumer下一次拉取,broker依然会发送该消息。
所以,任何异常都要捕获返回ConsumeConcurrentlyStatus.RECONSUME_LATER,rocketmq会放到重试队列。
这个重试TOPIC的名字是
%RETRY%+consumergroup的名字
在控制台上过一会就可以查到。
重试的消息在延迟的某个时间点(默认是10秒,业务可设置)后,再次投递到这个ConsumerGroup。而如果一直这样重复消费都持续失败到一定次数(默认16次),就会投递到DLQ死信队列,此时需要人工干预了。
消息重试的间隔时间可以在broker端配置:
在broker的配置文件里配置:messageDelayLevel =1s 5s 10s 30s 1m 2m 3m 4m 5m 6m 7m 8m 9m 10m 20m 30m 1h 2h
例如:
我的重试间隔时间为5秒,订阅死信队列的消费端收到消息并打印。
7、消息轨迹
1.Broker配置 首先看下broker.conf配置的两个属性
属性 |
默认值 |
---|---|
traceTopicEnable |
false |
msgTraceTopicName |
RMQ_SYS_TRACE_TOPIC |
RocketMQ之八:重试队列,死信队列,消息轨迹的更多相关文章
- SpringCloud 2020.0.4 系列之 Stream 消息出错重试 与 死信队列 的实现
1. 概述 老话说的好:出错不怕,怕的是出了错,却不去改正.如果屡次出错,无法改对,就先记下了,然后找援军解决. 言归正传,今天来聊一下 Stream 组件的 出错重试 和 死信队列. RabbitM ...
- RabbitMQ与.net core(四) 消息的优先级 与 死信队列
1.消息的优先级 假如现在有个需求,我们需要让一些优先级最高的通知推送到客户端,我们可以使用redis的sortedset,也可以使用我们今天要说的rabbit的消息优先级属性 Producer代码 ...
- Spring Boot系列——死信队列
在说死信队列之前,我们先介绍下为什么需要用死信队列. 如果想直接了解死信对接,直接跳入下文的"死信队列"部分即可. ack机制和requeue-rejected属性 我们还是基于上 ...
- RabbitMQ 消费端限流、TTL、死信队列
目录 消费端限流 1. 为什么要对消费端限流 2.限流的 api 讲解 3.如何对消费端进行限流 TTL 1.消息的 TTL 2.队列的 TTL 死信队列 实现死信队列步骤 总结 消费端限流 1. 为 ...
- 【RabbitMQ】一文带你搞定RabbitMQ死信队列
本文口味:爆炒鱿鱼 预计阅读:15分钟 一.说明 RabbitMQ是流行的开源消息队列系统,使用erlang语言开发,由于其社区活跃度高,维护更新较快,性能稳定,深得很多企业的欢心(当然,也包括我 ...
- RabbitMQ TTL、死信队列
TTL概念 TTL是Time To Live的缩写,也就是生存时间. RabbitMQ支持消息的过期时间,在消息发送时可以进行指定. RabbitMQ支持队列的过期时间,从消息入队列开始计算,只要超过 ...
- RabbitMQ之死信队列
1:何为死信队列 死信队列也是一个正常的队列,可以被消费. 但是,死信队列的消息来源于其他队列的转发. 2:如何触发死信队列 1:消息超时 2:队列长度达到极限 3:消息被拒绝消费,并不再重进队列,且 ...
- 【MQ中间件】RabbitMQ -- RabbitMQ死信队列及内存监控(4)
1.RabbitMQ TTL及死信队列 1.1.TTL概述 过期时间TTL表示可以对消息设置预期的时间,在这个时间内都可以被消费者接收获取:过了之后消息将自动被删除.RabbitMQ可以对消息和队列设 ...
- rabbitmq~消息失败后重试达到 TTL放到死信队列(事务型消息补偿机制)
这是一个基于消息的分布式事务的一部分,主要通过消息来实现,生产者把消息发到队列后,由消费方去执行剩下的逻辑,而当消费方处理失败后,我们需要进行重试,即为了最现数据的最终一致性,在rabbitmq里,它 ...
随机推荐
- maven热部署插件-jetty
作者:小勇Oo 关于maven-jetty-plugin的说明: pom文件中: <build> <finalName>freemarker</finalName> ...
- MySQL 下载与安装使用教程
MySQL 官网地址:https://www.mysql.com/ 等待下载完成 双击运行 如果有需要 我们可以新增一个用户出来 点击 Add User,不需要的话 直接 点击 next 默认的MyS ...
- Beyond Compare 4 使用30天后过期续用方法
Beyond Compare 4 使用30天后过期续用方法 windows上的Beyond Compare 4软件过期了,两个方法: 方案一: 找到Beyond Compare 4安装目录,安装时默认 ...
- 题解 noip2019模拟赛Day1T3
题面 运河计划 问题描述 水运在人类的交通运输史中一直扮演着重要的角色.借助河流.的便利,人们得以把大量的货物输送到天南海北不仅仅是自然界现成的河流,人工开凿的运河(如苏伊士运河.巴拿马运河.我国的京 ...
- SP4546 ANARC08A - Tobo or not Tobo IDA*
题意:
- PHP mysqli_fetch_assoc() 函数
从结果集中取得一行作为关联数组: <?php // 假定数据库用户名:root,密码:123456,数据库:RUNOOB $con=mysqli_connect("localhost& ...
- BZOJ 1097: [POI2007]旅游景点atr 状态压缩+Dijkstra
题解: $k<=20,$ 考虑状压dp. 从 $1$ 号点走到 $n$ 号点经过的点的个数可能会非常多,但是强制要求经过的点一共才 $20$ 个. 而我们发现这个题好就好在可以经过某个城市,而不 ...
- 路由器配置——广播多路访问链路上的OSPF
一.实验目的:作广播形式的OSPF,了解DR与BDR之间的链路关系 二.拓扑图: 三.具体步骤配置 (1)R1路由器配置 enableconfigure terminalhostname R1inte ...
- 51 Nod 1449 砝码称重
1449 砝码称重 题目来源: CodeForces 基准时间限制:1 秒 空间限制:131072 KB 分值: 40 难度:4级算法题 收藏 关注 现在有好多种砝码,他们的重量是 w0,w1, ...
- ssh登陆强制使用密码验证登陆
Linux系统使用ssh进行登陆,可以采用密码登陆和秘钥登陆.采用密码登陆每次需要输入密码进行验证,验证通过则可登陆到环境. 秘钥登陆为在服务器的客户端生成相应的公钥和私钥,公钥用于加密,私钥用于解密 ...