消息的按序处理

本文来说下消息的按序处理

---

概述

消息的按序也不能完全依靠于TCP，在说到消息中间件的时候，我们通常都会谈到一个特性：消息的顺序消费问题。这个问题看起来很简单：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个队列。

---

业务需要全局有序吗

通过上面分析可以看出，要保证一个topic内部，消息严格的有序，是很困难的，或者说条件是很苛刻的。那怎么办呢?我们一定要使出所有力气、用尽所有办法，来保证消息的严格有序吗?

实际情况中：（1)不关注顺序的业务大量存在；(2）队列无序不代表消息无序。

---

kafka保证数据的顺序性

kafka 写入partion时指定一个key，列如订单id，那么消费者从partion中取出数据的时候肯定是有序的，当开启多个线程的时候可能导致数据不一致，这时候就需要内存队列，将相同的hash过的数据放在一个内存队列里，这样就能保证一条线程对应一个内存队列的数据写入数据库的时候顺序性的，从而可以开启多条线程对应多个内存队列。

kafka：一个topic，一个partition，一个consumer，内部单线程消费，写N个内存queue，然后N个线程分别消费一个内存queue即可。

kafka每个partition中的消息在写入时都是有序的，消费时，每个partition只能被每一个group中的一个消费者消费，保证了消费时也是有序的。整个topic不保证有序。如果为了保证topic整个有序，那么将partition调整为1。

综上，我看到，在分布式系统中，要想消息有顺序的被消费，无论是Kafka还是Rocketmq都要想办法让有顺序的消息被同一消费者消费，而不是并发的消费，在消费者消费成功后，接着才会消费下一个消息，这样就可以保证了严格的顺序。

---

本文小结

从上面的分析可以看出，要保证消息的严格有序，有多么困难！发送端和接收端的问题，还好解决一点，限制异步发送，限制并行消费。但对于存储端，机器挂了之后，切换的问题，就很难解决了。你切换了，可能消息就会乱；你不切换，那就暂时不可用。这2者之间，就需要权衡了。