一. 消息发送重试
生产者在发送消息时，同步消息失败会重投，异步消息有重试，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重试消息的压力
三. 重试队列
- 考虑到异常恢复起来需要一些时间，会为重试队列设置多个重试级别，每个重试级别都有与之相应的重投延时，重试次数越多投递延时就越大。RocketMQ对于重试消息的处理是先保存至Topic名称为“SCHEDULE_TOPIC_XXXX”的延迟队列中，后台定时任务按照对应的时间进行延时后重新投递至"%RETRY%+consumerGroup"重试队列中。
- RocketMQ会为每个消费组设置一个Topic名称为"%RETRY%+consumerGroup"的重试队列（这里需要注意的是，这个Topic的重试队列是针对消费者组的，而不是针对每个Topic设置的），用于暂时保存因为各种异常而导致Consumer端无法消费的消息
- 延时级别
messageDelayLevel=1s 5s 10s 30s 1m 2m 3m 4m 5m 6m 7m 8m 9m 10m 20m 30m 1h 2h