前言
如何保证消息的顺序性
其实这个也是用
MQ的时候必问的话题，主要想请问了不了解顺序，其次是如何保证消息是有顺序。这是生产系统中常见的问题。
问题剖析
一个 mysqlbinlog 同步的系统，压力还是非常大的，日同步数据要达到上亿，就是说数据从一个 mysql库原封不动地同步到另一个 mysql 库里面去（mysql -> mysql）。
在mysql里增删改一条数据，对应出来了增删改 3 条 binlog 日志，接着这三条 binlog 发送到MQ里面，再消费出来依次执行，起码需要保证是按照顺序。
不然本来是：增加、修改、删除；你愣是换了顺序给执行成删除、修改、增加，不全错了么。
本来这个数据同步过来，应该最后这个数据被删除了；结果搞错了这个顺序，最后这个数据保留下来了，数据同步就出错了。
先看看顺序会错乱的俩场景：
RabbitMQ：一个queue，多个consumer。比如，生产者向RabbitMQ里发送了三条数据，顺序依次是data1/data2/data3，压入的是RabbitMQ的一个内存队列。有三个消费者分别从MQ中消费这三条数据中的一条，结果消费者 2 先执行完操作，把data2存入数据库，然后是data1/data3。这不明显乱了。
Kafka：比如说我们建了一个topic，有三个partition。生产者在写的时候，其实可以指定一个key，比如说我们指定了某个订单id作为key，那么这个订单相关的数据，一定会被分发到同一个partition中去，而且这个partition中的数据一定是有顺序的。 消费者从partition中取出来数据的时候，也一定是有顺序的。到这里，顺序还是 ok 的，没有错乱。
接着，我们在消费者里可能会搞多个线程来并发处理消息。因为如果消费者是单线程消费处理，而处理比较耗时的话，比如处理一条消息耗时几十 ms，那么 1 秒钟只能处理几十条消息，这吞吐量太低了。而多个线程并发跑的话，顺序可能就乱掉了。
解决方案
RabbitMQ
拆分多个 queue，每个 queue 一个 consumer，就是多一些 queue 而已，确实是麻烦点，这样也会造成吞吐量下降，可以在消费者内部采用多线程的方式取消费。
或者就一个 queue 但是对应一个 consumer，然后这个 consumer 内部用内存队列做排队，然后分发给底层不同的 worker 来处理。
注意，这里消费者不直接消费消息，而是将消息根据关键值（比如：订单 id）进行哈希，哈希值相同的消息保存到相同的内存队列里。也就是说，需要保证顺序的消息存到了相同的内存队列，然后由一个唯一的 worker 去处理。
Kafka
- 一个 topic，一个 partition，一个 consumer，内部单线程消费，单线程吞吐量太低，一般不会用这个。
- 写 N 个内存 queue，具有相同 key 的数据都到同一个内存 queue；然后对于 N 个线程，每个线程分别消费一个内存 queue 即可，这样就能保证顺序性。
