内容简介:RocketMQ集群消费的时候,我们经常看到类似注释里面 (1,(2 的写法,已经有时候有同学没注意抛异常的情况就是(3 模拟的情况。那么这3种情况到底是怎么样的呢?你是否都了然于心呢?下面我们一起来看看吧,本文主要在讲解RocketMQ集群消费有些内容会提到但是不会深入讲解(以后有机会讲其他的)。虽然说是PushConsumer其实本质还是拉。
说明
RocketMQ集群消费的时候,我们经常看到类似注释里面 (1,(2 的写法,已经有时候有同学没注意抛异常的情况就是(3 模拟的情况。那么这3种情况到底是怎么样的呢?你是否都了然于心呢?下面我们一起来看看吧,本文主要在讲解RocketMQ集群消费有些内容会提到但是不会深入讲解(以后有机会讲其他的)。
RocketMQ集群消费执行过程
虽然说是PushConsumer其实本质还是拉。
再跟进去
在继续跟进
Netty推荐使用addListener的方式来回调异步执行的结果。,关于opaque这个在 RocketMQ(二):RPC通讯 详细说明了。
当到broker拉取的数据返回之后:
获取到拉请求的时候存入的opaque。执行异步回调:
到这里开始执行消费情况了。
消费提交线程池。
到这里就到了真正执行消费端代码了,就是我们最开始的这个代码了:
分析
由于有3种情况,那么重点就在下面这个status这行代码了。
就是最开始讨论的三种情况了,staus的值就对应(1 (2 (3 情况了。
(1 ==》成功,status 就是成功状态
(2 ==》重试,status就是重试状态
(3 ==》null,抛异常了,status最终还是会被标记为重试状态
备注:RocketMQ最佳实践,不建议抛异常,而建议返回重试状态。
关键就在于分析这块了。
其实如果批消费400条,假如前399条都成功了,最后一条失败,返回重试的话,这400条都会发送bak到broker上面的 ,值得注意,并不是理所当然的那种就最后一条重试 。
关于RPC这块,建议看看 RocketMQ(二):RPC通讯 ,我们看看broker端的处理:
进行跟进
消费端发送bak过来的delayLevel都是0,重新根据消费次数+3设置,之后把消费次数+1,之后进行存储消息。
后面存储就和正常存在一样了,那么消息怎么再次投递呢? 如果一直投递怎么可能?
每重试一次reconsumeTimes都会+1,一直到16次(默认)
会放到DLQ死信队列。
定时消息由于涉及到内容太多,准备下次分享。
结论
通过上面分析,应该可以明白RocketMQ集群消费的大体逻辑以及执行情况,以及最佳实践,并且知道了如果一批消费n(n>1),如果最后有一条消费失败,导致发送了消费重试,那么这n条都会进行重试的。
文章github源代码地址: rocketmq ,或者公号回复“ rocketmq ”获取源码地址。
以上就是本文的全部内容,希望本文的内容对大家的学习或者工作能带来一定的帮助,也希望大家多多支持 码农网
猜你喜欢:- 消费端如何保证消息队列MQ的有序消费
- 《吊打面试官》系列-分布式事务、重复消费、顺序消费
- 十一贝:航延险智能判定,公平消费环境惠及消费者
- Kafka消费者的偏移量和高级/简单消费者
- RocketMQ 实战:一个新的消费组初次启动时从何处开始消费呢?
- RocketMQ的消费模式
本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。
HTML 压缩/解压工具
在线压缩/解压 HTML 代码
XML 在线格式化
在线 XML 格式化压缩工具