RocketMQ集群消费的那些事

说明

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”获取源码地址。

---

若是读完以为有收获的话，欢迎点赞、关注、加公众号【匠心零度】，查阅更多精彩历史！！！