在说到消息中间件的时候，我们通常都会谈到一个特性：消息的顺序消费问题。这个问题看起来很简单：Producer发送消息1, 2, 3。。。 Consumer按1, 2, 3。。。顺序消费。
但实际情况却是：无论RocketMQ，还是Kafka，缺省都不保证消息的严格有序消费！
这个特性看起来很简单，但为什么缺省他们都不保证呢？
有兴趣朋友可以关注公众号“架构之道与术”， 获取最新文章和进一步讨论。
或扫描如下二维码：
下面就从3个方面来分析一下，对于一个消息中间件来说，”严格的顺序消费”有多么困难，或者说不可能。
发送端不能异步发送，异步发送在发送失败的情况下，就没办法保证消息顺序。
比如你连续发了1，2，3。 过了一会，返回结果1失败，2, 3成功。你把1再重新发送1遍，这个时候顺序就乱掉了。
对于存储端，要保证消息顺序，会有以下几个问题：
（1）消息不能分区。也就是1个topic，只能有1个队列。在Kafka中，它叫做partition；在RocketMQ中，它叫做queue。 如果你有多个队列，那同1个topic的消息，会分散到多个分区里面，自然不能保证顺序。
（2）即使只有1个队列的情况下，会有第2个问题。该机器挂了之后，能否切换到其他机器？也就是高可用问题。
比如你当前的机器挂了，上面还有消息没有消费完。此时切换到其他机器，可用性保证了。但消息顺序就乱掉了。
要想保证，一方面要同步复制，不能异步复制；另1方面得保证，切机器之前，挂掉的机器上面，所有消息必须消费完了，不能有残留。很明显，这个很难！！！
对于接收端，不能并行消费，也即不能开多线程或者多个客户端消费同1个队列。
从上面的分析可以看出，要保证消息的严格有序，有多么困难！
发送端和接收端的问题，还好解决一点，限制异步发送，限制并行消费。但对于存储端，机器挂了之后，切换的问题，就很难解决了。
你切换了，可能消息就会乱；你不切换，那就暂时不可用。这2者之间，就需要权衡了。
通过上面分析可以看出，要保证一个topic内部，消息严格的有序，是很困难的，或者说条件是很苛刻的。
那怎么办呢？我们一定要使出所有力气、用尽所有办法，来保证消息的严格有序吗？
这里就需要从另外一个角度去考虑这个问题：业务角度。正如在下面这篇博客中所说的：
http://www.jianshu.com/p/453c6e7ff81c
实际情况中：
（1）不关注顺序的业务大量存在；
（2） 队列无序不代表消息无序。
第（2）条的意思是说：我们不保证队列的全局有序，但可以保证消息的局部有序。
举个例子：保证来自同1个order id的消息，是有序的！
下面就看一下在Kafka和RocketMQ中，分别是如何对待这个问题的：
Kafka中：发送1条消息的时候，可以指定(topic, partition, key) 3个参数。partiton和key是可选的。
如果你指定了partition，那就是所有消息发往同1个partition，就是有序的。并且在消费端，Kafka保证，1个partition只能被1个consumer消费。
或者你指定key（比如order id），具有同1个key的所有消息，会发往同1个partition。也是有序的。
RocketMQ： RocketMQ在Kafka的基础上，把这个限制更放宽了一步。只指定(topic, key)，不指定具体发往哪个队列。也就是说，它更加不希望业务方，非要去要一个全局的严格有序。
关键点：这个放开，其实牵涉到一个更大的问题。就是RocketMQ和Kafka在底层存储上面的重大差异。这个我在上1篇，”拨乱反正“”续篇中，有过介绍。
后面在源码分析序列中，会进一步分析这个问题。
关于“消息顺序”这个问题，就讨论到此为止。
