RocketMQ实战(二)

初步了解消息失败重试机制消息失败,无非涉及到2端:从生产者端发往MQ的失败;消费者端从MQ消费消息的失败;生产者端的失败重试
在这里插入图片描述

生产者端失败重试

生产者端的消息失败:比如网络抖动导致生产者发送消息到MQ失败。
上图代码示例的处理手段是:如果该条消息在1S内没有发送成功,那么重试3次。
消费者端的失败重试
消费者端的失败,分为2种情况,一个是timeout,一个是exception
timeout,比如由于网络原因导致消息压根就没有从MQ到消费者上,在RocketMQ内部会不断的尝试发送这条消息,直至发送成功为止!(比如集群中一个broker失败,就尝试另一个broker)
exception,消息正常的到了消费者,结果消费者发生异常,处理失败了。这里涉及到一些问题,需要我们思考下,比如,消费者消费消息的状态有哪些定义?如果失败,MQ将采取什么策略进行重试?假设一次性批量PUSH了10条,其中某条数据消费异常,那么消息重试是10条呢,还是1条呢?而且在重试的过程中,需要保证不重复消费吗?

在这里插入图片描述

ConsumeConcurrentlyStatus
消息消费的状态,有2种,一个是成功(CONSUME_SUCCESS),一个是失败&稍后重试(RECONSUME_LATER)

在这里插入图片描述

broker启动日志

在启动broker的过程中,可以观察下日志,你会发现RECONSUME_LATER的策略。
如果消费失败,那么1S后再次消费,如果失败,那么5S后,再次消费,…直至2H后如果消费还失败,那么该条消息就会终止发送给消费者了!
RocketMQ为我们提供了这么多次数的失败重试,但是在实际中也许我们并不需要这么多重试,比如重试3次,还没有成功,我们希望把这条消息存储起来并采用另一种方式处理,而且希望RocketMQ不要在重试呢,因为重试解决不了问题了!这该如何做呢?
我们先来看一下一条消息MessageExt对象的输出:MessageExt [queueId=0, storeSize=137, queueOffset=0, sysFlag=0, bornTimestamp=1492213846916, bornHost=/192.168.99.219:50478, storeTimestamp=1492213846981, storeHost=/192.168.99.121:10911, msgId=C0A8637900002A9F0000000000000000, commitLogOffset=0, bodyCRC=613185359, reconsumeTimes=0, preparedTransactionOffset=0, toString()=Message [topic=TopicTest2, flag=0, properties={TAGS=TagA, WAIT=true, MAX_OFFSET=3, MIN_OFFSET=0}, body=16]]注意到reconsumeTimes属性,这个属性就代表消息重试的次数!来看一段代码:

在这里插入图片描述

reconsumeTime的使用
注意了,对于消费消息而言,存在2种指定的状态(成功 OR 失败重试),如果一条消息在消费端处理没有返回这2个状态,那么相当于这条消息没有达到消费者,势必会再次发送给消费者!也即是消息的处理必须有返回值,否则就进行重发。

作者:张丰哲
链接:https://www.jianshu.com/p/790d6bc4a1c1
來源:简书
简书著作权归作者所有,任何形式的转载都请联系作者获得授权并注明出处。

猜你喜欢

转载自blog.csdn.net/pf1234321/article/details/86378283