【RocketMQ】重试

一. 消息发送重试

生产者在发送消息时,同步消息失败会重投,异步消息有重试,oneway没有任何保证。消息重投保证消息尽可能发送成功、不丢失,但可能会造成消息重复发送。消息重复发送在一般情况下不会发生,当出现消息量大、网络抖动,就会大概率出现。另外,生产者主动重发、consumer负载变化也会导致重复消息。如下方法可以设置消息重试策略:

  • retryTimesWhenSendFailed: 同步发送失败重投次数,默认为2,因此生产者最多会尝试发送retryTimesWhenSendFailed + 1次。且生产者不会选择上次失败的broker,而是尝试向其他broker发送,最大程度保证消息不丢。超过重投次数,抛出异常,由客户端保证消息不丢。当出现RemotingException、MQClientException和部分MQBrokerException时会重投。
  • retryTimesWhenSendAsyncFailed: 异步发送失败重试次数,异步重试不会选择其他broker,仅在同一个broker上做重试,不保证消息不丢(导致broker挂掉后消息一直无法发送出去)。
  • retryAnotherBrokerWhenNotStoreOK: 消息刷盘(主或备)超时或slave不可用(返回状态非SEND_OK),是否尝试发送到其他broker,默认false。十分重要消息可以开启。

二. 消息消费重试

Consumer消费消息失败后,要提供一种重试机制,令消息再消费一次。Consumer消费消息失败通常可以认为有以下几种情况:

  • 由于消息本身的原因,例如反序列化失败,消息数据本身无法处理等。这种错误通常需要跳过这条消息,再消费其它消息,而这条失败的消息即使立刻重试消费,99%也不成功,所以最好提供一种定时重试机制,即过10秒后再重试。
  • 由于依赖的下游应用服务不可用,例如db连接不可用,外系统网络不可达等。遇到这种错误,即使跳过当前失败的消息,消费其他消息同样也会报错。这种情况建议应用sleep 30s,再消费下一条消息,这样可以减轻Broker重试消息的压力

三. 重试队列

  1. 考虑到异常恢复起来需要一些时间,会为重试队列设置多个重试级别,每个重试级别都有与之相应的重投延时,重试次数越多投递延时就越大。RocketMQ对于重试消息的处理是先保存至Topic名称为“SCHEDULE_TOPIC_XXXX”的延迟队列中,后台定时任务按照对应的时间进行延时后重新投递至"%RETRY%+consumerGroup"重试队列中。
  1. RocketMQ会为每个消费组设置一个Topic名称为"%RETRY%+consumerGroup"的重试队列(这里需要注意的是,这个Topic的重试队列是针对消费者组的,而不是针对每个Topic设置的),用于暂时保存因为各种异常而导致Consumer端无法消费的消息
  1. 延时级别
messageDelayLevel=1s 5s 10s 30s 1m 2m 3m 4m 5m 6m 7m 8m 9m 10m 20m 30m 1h 2h
posted @ 2021-11-29 18:06    阅读(112)  评论(0编辑  收藏  举报