RocketMQ集群消费的那些事

1545786088325

RocketMQ集群消费的时候,我们经常看到类似注释里面 (1,(2 的写法,已经有时候有同学没注意抛异常的情况就是(3 模拟的情况。那么这3种情况到底是怎么样的呢?你是否都了然于心呢?下面我们一起来看看吧,本文主要在讲解RocketMQ集群消费有些内容会提到但是不会深入讲解(以后有机会讲其他的)。

RocketMQ集群消费执行过程

虽然说是PushConsumer其实本质还是拉。

1545786434718

再跟进去

1545786614319

在继续跟进

1545787539942

Netty推荐使用addListener的方式来回调异步执行的结果。,关于opaque这个在详细说明了。

1545787725239

当到broker拉取的数据返回之后:

1545788118008

1545788142967

1545788207886

获取到拉请求的时候存入的opaque。执行异步回调:

1545788344401

1545788377060

1545788437626

1545788484314

到这里开始执行消费情况了。

1545788617363

消费提交线程池。

1545788746965

到这里就到了真正执行消费端代码了,就是我们最开始的这个代码了:

1545786088325

分析

由于有3种情况,那么重点就在下面这个status这行代码了。

1545788746965

就是最开始讨论的三种情况了,staus的值就对应(1 (2 (3 情况了。

(1 ==》成功,status 就是成功状态

(2 ==》重试,status就是重试状态

(3 ==》null,抛异常了,status最终还是会被标记为重试状态

1545790100863

备注:RocketMQ最佳实践,不建议抛异常,而建议返回重试状态。

1545790518896

1545789469552

关键就在于分析这块了。

1545791303927

其实如果批消费400条,假如前399条都成功了,最后一条失败,返回重试的话,这400条都会发送bak到broker上面的,值得注意,并不是理所当然的那种就最后一条重试

1545792247486

关于RPC这块,建议看看,我们看看broker端的处理:

1545792346141

进行跟进

1545792417738

1545792730563

消费端发送bak过来的delayLevel都是0,重新根据消费次数+3设置,之后把消费次数+1,之后进行存储消息。

1545793192069

后面存储就和正常存在一样了,那么消息怎么再次投递呢? 如果一直投递怎么可能?

每重试一次reconsumeTimes都会+1,一直到16次(默认)

1545794121109

会放到DLQ死信队列。

定时消息由于涉及到内容太多,准备下次分享。

结论

内容版权声明:除非注明,否则皆为本站原创文章。

转载注明出处:https://www.heiqu.com/wpjswp.html