RocketMQ(二)消息重试、死信队列、消息幂等

接上一章节RocketMQ(一)之消息类型简单描述

RockMQ的自动重试机制

• RockMQ自动重试触发机制有3种

返回Action.Reconsumelater。（官方推荐做法）
返回null。
返回异常。

• 自动重试机制会自动创建重试队列
• 默认重试16次，仍然失败，消息不在投递，转为进入死信队列。
• 自动重试使用的是延迟级别的后16个时间级别
• 可指定重试次数，但16次之后，重试时间级别都是2h

//设置重试次数
consumer.setMaxReconsumeTimes(20);

RockMQ死信队列

• 一个死信队列对应一个ConsumGroup，而不是对应某个消费者实例
• 如果一个ConsumGroup没有产生死信，RocketMQ默认是不会创建对应的死信队列
• 一个死信队列包含了这个ConsumGroup里的所有死信消息，而不区分消息属于哪个Topic。
• 死信队列中的消息不会被正常的消费者消费
• 死信队列的有效期与正常消息相同，默认3天。对应broker.conf的fileReseredTime属性，超过这个最长时间的消息会被删除，不管是否消费过
• 默认创建的死信队列，消息无法被读取，在控制台和消费者中都无法读取
• 默认的死信队列的权限perm被设置成2(禁读)，perm的权限有三种2(禁读)、4(禁写)、6(可读写)。
• 要手动将死信队列的权限修改成6，才能被消费。可以通过MQadmin或者控制台指定。

RockMQ消息幂等

• at most once最多一次：每条消息最多只会被消费一次
  at most once最好保证，RocketMQ中可以直接使用异步发送，sendOneWay就可以保证
• at least once至少一次：每条消息至少会被消费一次。
  RoctekMQ同步发送机制，事物消息方式可以保证
• exactly once刚好一次：每条消息都只会确定的消费一次。
  这个可以由系统开发者自行解决，例如引入分布式锁，确定数据库中的数据是否存在、是否被修改成指定值等。