rocketMQ生产者重试机制

三种消息的类型介绍如下：

1. 普通消息：消息是无序的，任意发送发送哪一个队列都可以。
2. 普通有序消息：同一类消息(例如某个用户的消息)总是发送到同一个队列，在异常情况下，也可以发送到 其他队列。
3. 严格有序消息：消息必须被发送到同一个队列，即使在异常情况下，也不允许发送到其他队列。

对于这三种类型的消息，RocketMQ分别提供了对应的方法来发送消息，例如同步发送(异步/批 量/oneway也是类似)：

//普通消息：不需要指定MessageQueue或者MessageQueueSelector参数
 SendResult send(final Message msg) 
 //普通有序消息：指定MessageQueueSelector参数，动态决定需要发送到哪个队列，出现异常情况下，才 发送到其他对下列 
 SendResult send(final Message msg, final MessageQueueSelector selector, final Object arg)
  //严格有序消息：指定MessageQueue参数，明确指定发送到哪个队列，如我们可以将一个用户的数据总是发 送到某个队列 
  SendResult send(final Message msg, final MessageQueue mq)

普通消息的重试

对于普通消息，消息发送默认采用round-robin机制来选择发送到哪一个队列，如果发送失败，默认重试2次。
由于之前发送失败的Queue必然位于某个Broker上，在重试过程中，这个失败的Broker上的Queue都不会选择，
why?
既然发送到这个Broker上某个Queue失败了，那么发送到这个Broker上的Queue失败的可能性依然很大, 所以选择其他Broker。
但是一定会这样吗？

例如Broker集群只是由一组Master/Slave组成，发送消息只会选择Master，如果这个Master失败
了，没有其他Master可选，此时已然会选择这个Master上的其他Queue。

在实际生产环境中，通常Broker集群至少由2组Master/Slave组成，甚至更多，一般建议：3主3从

这样就可以很好的利用RocketMQ对于普通消息发送的重试机制，每次重试到不同的Broker上。

从源码层面来看，对于普通消息，RocketMQ选择队列默认是通过
MQFaultStrategy#selectOneMessageQueue 来选择一个的队列，在未开启延迟容错的情况下，内部会调用 TopicPublishInfo#selectOneMessageQueue方法，这个方法源码体现了前面说的重试逻辑：

TopicPublishInfo#selectOneMessageQueue(java.lang.String)

public MessageQueue selectOneMessageQueue(final String lastBrokerName) {
    //1 消息第一次发送，上一个失败的broker名字为null，直接round-round选择 
    if (lastBrokerName == null) {
        return selectOneMessageQueue();
    } else {
        //2 消息发送失败重试(上一个失败的broker不为null)优先选择其他Broker上的队列
        int index = this.sendWhichQueue.getAndIncrement();
        for (int i = 0; i < this.messageQueueList.size(); i++) {
            int pos = Math.abs(index++) % this.messageQueueList.size();
            if (pos < 0) pos = 0;
            MessageQueue mq = this.messageQueueList.get(pos);
            //选择其他Broker上的队列
            if (!mq.getBrokerName().equals(lastBrokerName)) {
                return mq;
            }
        }
        //3 没有其他的Broker可选，那么依然round-robin，可能会选择到之前失败的Broker上 的队列
        return selectOneMessageQueue();
    }
}

事情到这里并没有结束，这段代码只是单次发送消息失败重试选择队列的逻辑。
实际情况可能是，在Broker宕机期间，可能会发送多条消息，那么每次都可能会选择到失败的Broker上 的Queue，然后再重试，尽管重试可能会成功，但是每次发送消息的耗时会增加。
因此，MQFaultStrategy实际上还提供了以下两个功能：

• 失败隔离：即发送消息到某个broker失败之后，将其进行隔离，优先从其他正常的broker中进行选择
• 延迟隔离：优先发送消息到延迟比较小的broker
  对于无序消息，通过这种异常重试机制，就可以保证消息发送的高可用了。

同时由于不需要NameServer通知众多不固定的生产者，也降低了NameServer实现的复杂性。