12.RocketMQ之消息重试机制+死信队列

一、消息的消费重试机制

Producer对发送失败的消息进行重新发送的机制。
采用同步或异步会重试,oneway消息发送方式发送失败没有重试机制。
消息发送重试三种策略:

  1. 同步发送失败策略
    对于普通消息,消息发送默认采用round-robin策略来选择所发送到的队列。如果发送失败,默认重试2次,但在重试时是不会选择上次发送失败的Broker,而是选择其他的Broker。
    同时,Broker还具有失败隔离功能,使Producer尽量选择未发生过发送失败的Broker作为目标Broker。
    如果超过重试次数,则抛出异常,由Producer去保证消息不丢。当然当生产者出现RemotingException、MQClientException和MQBrokerException时,Producer会自动重投消息。
  2. 异步发送失败策略
    异步发送失败重试时,异步重试不会选择其他broker,仅在同一个broker上做重试,所以该策略无法保证消息不丢。
  3. 消息刷盘失败策略
    消息刷盘超时或是slave不可用(slave同步数据时向master返回状态非SEND_OK)时,默认是不会将消息尝试发送到其他Broker的。不过,对于重要消息可以通过在Broker的配置文件设置retryAnotherBrokerWhenNotStoreOK属性为true来开启。

二、消息消费重试机制

  1. 顺序消息的消费重试
    对于顺序消息,当Consumer消费消息失败后,为了保证消息的顺序性,其会自动不断地进行消息重试,直到消费成功。重试期间应用会出现消息消费被阻塞的情况。对于顺序消息的重试是无休止的,不间断的,直至消费成功,所以,对于顺序消息的消费,务必要保证应用能够及时监控并处理消费失败的情况,避免消费被永久性阻塞。
    顺序消息没有发送失败重试机制,但是有消费失败重试。
  2. 无序消息(普通消息、延时消息、事务消息)的消费重试
    当Consumer消费消息失败时,可以通过设置返回状态达到消息重试的效果。无序消息的重试只对集群消费方式生效,广播方式不提供失败重试特性,一个消费失败还有其他消费者进行消费。
    12.RocketMQ之消息重试机制+死信队列_第1张图片
    请添加图片描述
    对于修改过的重试次数,若修改值小于16,则按照指定间隔进行重试,若大于16的重试时间间隔均为2小时。对于Consumer Group只修改一个,则会应用到所有的其他Consumer实例。多个都修改,采用覆盖采取最后一个修改 的值。若消息还失败,将投入到死信队列。
  3. 重试队列:存储所有需要重试消费的消息的特殊topic队列。针对消息组的,不是topic,一个topic的消息可以让多个消费者组消费,所以会为这些消费者组各创建一个重试队列。
  4. 消费重试配置方式:集群消费方式下,消息消费失败后若希望消费重试,则需要在消息监听器接口实现明确的返回值:
    方式1:返回ConsumeConcurrentlyStatus.RECONSUME_LATER(官方推荐)
    方式2:返回NULL
    方式3:抛出异常
    12.RocketMQ之消息重试机制+死信队列_第2张图片
  5. 消息不重试配置方式:ConsumeConcurrentlyStatus.CONSUME_SUCCESS

三、死信队列

当一条消息消费重试达到最大重试次数后仍然消费失败,此时队列将消息扔到特殊的队列中,这个队列就是死信队列。

  1. 特征:死信队列中消息消费者看不到消息,无法再次消费;死信队列中消息和正常消息有效期一样(Commitlog文件中设置3天);死信队列就是一个特殊的Topic,名称为%DLQ%consumerGroup@ consumerGroup;如果一个消费者组未产生死信消息,则不会为其创建相应的死信队列。
  2. 死信消息的实际处理:
    实际上,当一条消息进入死信队列意味着系统出现某些问题,代码存在bug。对于死信消息手工处理。

你可能感兴趣的:(RocketMQ,java,中间件)