- 普通消息：消息是无序的，任意发送发送哪一个队列都可以。普通有序消息：同一类消息(例如某个用户的消息)总是发送到同一个队列，在异常情况下，也可以发送到 其他队列。严格有序消息：消息必须被发送到同一个队列，即使在异常情况下，也不允许发送到其他队列。
对于这三种类型的消息，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实现的复杂性。
