当前位置:   article > 正文

JAVA面试题分享一百六十:RocketMQ的死信队列?_rocketmq有死信队列吗

rocketmq有死信队列吗

目录

一、前言

二、重试队列

三、什么是死信队列

四、死信队列的特征

五、死信消息的处理

六、死信队列默认无法消费


一、前言

消费者中我们注册了一个监听器回调函数,当Consumer获取消息后,就会交给我们的回调函数来进行处理。如果处理完了,就返回一个ConsumeConcurrentlyStatus.CONSUME_SUCCESS,提交这批消息的offset到broker去,然后继续从broker获取下一批消息来进行处理。 如果上面代码回调函数中,对一批消息处理的时候,数据库宕机了就不能再能返回CONSUME_SUCCESS,如果你返回的话,下一次就会处理下一批消息,但是这批消息其实没处理成功,此时必然导致这批消息就丢失了;

返回RECONSUME_LATER

  1. consumer.registerMessageListener(
  2. new MessageListenerConcurrently() {
  3. @Override
  4. public ConsumeConcurrentlyStatus consumeMessage(
  5. List<MessageExt> msgs,
  6. ConsumeConcurrentlyContext context) {
  7. try {
  8. // 后续消息处理逻辑
  9. return ConsumeConcurrentlyStatus.CONSUME_SUCCESS;
  10. } catch (Exception e) {
  11. // 比如因为数据库宕机了,没法对消息完成处理
  12. // 此时可以返回一个稍后重试的消费状态
  13. return ConsumeConcurrentlyStatus.RECONSUME_LATER;
  14. }
  15. }
  16. }
  17. }
  18. );

如果消费端消费失败的话,过段时间再次给我这批消息重试;

二、重试队列

只有当消费模式为集群模式时,Broker 才会自动进行重试,对于广播消息是不会重试的;

RocketMQ会有一个针对你这个ConsumerGroup的重试队列,如果你返回了RECONSUME_LATER状态,他就会把你这批消息放到你这个消费组的重试队列中去,比如消费组是"WMSConsumerGroup",那么就会有一个“%RETRY%WMSConsumerGroup”,这个名字的重试队列;

然后过一段时间,重试队列中的消息会再次进行处理,如果再次失败,又返回了RECONSUME_LATER,那么会再过一段时间让我们再次进行处理,默认最多重试16次;每次重试之间的间隔时间是不一样的,这个间隔时间可以如下进行配置:

messageDelayLevel=1s 5s 10s 30s 1m 2m 3m 4m 5m 6m 7m 8m 9m 10m 20m 30m 1h 2h

意思就是,第一次重试是1秒后,第二次重试是5秒后,第三次重试是10秒后,第四次重试是30秒后,第五次重试是1分钟后,以此类推,最多重试16次;

  1. 所有的延迟消息到达broker后,会存放到SCHEDULE_TOPIC_XXX的topic下(这个topic比较特殊,对客户端是不可见的,包括使用rocketmq-console,也查不到这个topic);
  2. SCHEDULE_TOPIC_XXX这个topic下存在18个队列,每个队列中存放的消息都是同一个延迟级别消息;
  3. broker端启动了一个timer和timerTask的任务,定时从此topic下拉取数据,如果延迟时间到了,就会把此消息发送到指定的topic下,完成延迟消息的发送;

刚才我们说如果你返回了RECONSUME_LATER,消息就会进入重试队列,其实不完全准确;

当MQ接收到RECONSUME_LATER后,首先会完成消息的转换,把消息存到延时队列中,然后再根据消息的延时时间保存到重试队列中;

如果重试了16次之后依然无法处理,就会把这些消费放入死信队列。死信队列中的消息RocketMQ不会再做处理,这部分数据要怎么处理就要看我们的业务场景了,我们可以做一个后台线程去订阅这个死信队列,完成后续消息的处理;

三、什么是死信队列

如果在16次重试范围内消息处理成功了,自然就没问题了;但是如果对一批消息重试了16次还是无法成功处理,就需要另外一个队列了,叫做死信队列,死信队列的名字是“%DLQ%WMSConsumerGroup”;

对死信队列中的消息处理,这个就看具体需求,比如可以专门开一个后台线程,订阅“%DLQ%WMSConsumerGroup”这个死信队列,对死信队列中的消息进行不停的重试;

当一条消息初次消费失败,消息队列会自动进行消费重试;达到最大重试次数后,若消费依然失败,则表明消费者在正常情况下无法正确地消费该消息,此时,消息队列不会立刻将消息丢弃,而是将其发送到该消费者对应的特殊队列中。这个队列就是死信队列(Dead-Letter Queue,DLQ),而其中的消息则称为死信消息(Dead-Letter Message,DLM)。

死信队列是用于处理无法被正常消费的消息的。

四、死信队列的特征

死信队列具有如下特征:

  • 死信队列中的消息不会再被消费者正常消费,即DLQ对于消费者是不可见的
  • 死信存储有效期与正常消息相同,均为 3 天(commitlog文件的过期时间),3 天后会被自动删除
  • 死信队列就是一个特殊的Topic,名称为%DLQ%consumerGroup ,即每个消费者组都有一个死信队列
  • 如果⼀个消费者组未产生死信消息,则不会为其创建相应的死信队列

五、死信消息的处理

实际上,当⼀条消息进入死信队列,就意味着系统中某些地方出现了问题,从而导致消费者无法正常消费该消息,比如代码中原本就存在Bug。因此,对于死信消息,通常需要开发人员进行特殊处理。最关键的步骤是要排查可疑因素,解决代码中可能存在的Bug,然后再将原来的死信消息再次进行投递消费。

六、死信队列默认无法消费

死信的perm默认是2,表示只写。

perm用于设置对当前创建Topic的操作权限:2表示只写,4表示只读,6表示读写。

如果想消费死信队列的消息,需要修改perm的值为6,便可消费

声明:本文内容由网友自发贡献,不代表【wpsshop博客】立场,版权归原作者所有,本站不承担相应法律责任。如您发现有侵权的内容,请联系我们。转载请注明出处:https://www.wpsshop.cn/w/煮酒与君饮/article/detail/1003097
推荐阅读
相关标签
  

闽ICP备14008679号