001 Kafka如何保证消息的顺序性

kafka的Consumer均衡算法
在说顺序性这个问题之前，我们要先搞明白的是消费者是怎么消费分区上的数据。
我们这里不详细讨论该算法，这不是本文的重点。
简单的说：

kafka的消费组的组员最多增加到和partition数量一致，超过的组员只会占用资源，而不起作用；

kafka的partition的个数一定要大于消费组组员的个数，并且partition的个数对于消费组组员取模一定要为0，不然有些消费者会占用资源却不起作用；

我们一般将消费组里组员的个数设置为和partition的数量相同。

消息顺序错乱问题
我们都知道Kafka是分布式多partition的，它会将一个topic中的消息尽可能均匀的分发到每个partition上。那么问题就来了，这样怎么保证同一个topic消息的顺序呢？

由于消费者是并行处理消息的，我们就无法保证消息的顺序性。

如何发送顺序消息
这个其实也很简单。
kafka可以通过partitionKey，将某类消息写入同一个partition，一个partition只能对应一个消费线程，以保证数据有序。
也就是说生产者在写消息的时候，可以指定一个 key，比如说我们指定了某个订单 id 作为 key，那么这个订单相关的数据，一定会被分发到同一个 partition 中去，而且这个 partition 中的数据一定是有顺序的。

Kafka如何保证单partition有序？
producer发消息到队列时，通过加锁保证有序。

那么是否有这样一个问题呢？
先后两条消息发送时，前一条消息发送失败，后一条消息发送成功，然后失败的消息重试后发送成功，造成乱序。

为了解决重试机制引起的消息乱序为实现Producer的幂等性，Kafka引入了Producer ID（即PID）和Sequence Number。

对于每个PID，该Producer发送消息的每个<Topic, Partition>都对应一个单调递增的Sequence Number。

同样，Broker端也会为每个<PID, Topic, Partition>维护一个序号，并且每Commit一条消息时将其对应序号递增。

对于接收的每条消息，如果其序号比Broker维护的序号大一，则Broker会接受它，否则将其丢弃

如果消息序号比Broker维护的序号差值比一大，说明中间有数据尚未写入，即乱序，此时Broker拒绝该消息

如果消息序号小于等于Broker维护的序号，说明该消息已被保存，即为重复消息，Broker直接丢弃该消息

发送失败后会重试，这样可以保证每个消息都被发送到broker

消费者从 partition 中取出来数据的时候，也一定是有顺序的。到这里，顺序还是 ok 的，没有错乱。

但是消费者这里还是可能会有多个线程来并发来处理消息，因为如果消费者是单线程消费数据，那么这个吞吐量太低了。而多个线程并发的话，顺序可能就乱掉了。

解决方案
消费者端创建多个内存队列，具有相同 key 的数据都路由到同一个内存 队列；然后每个线程分别消费一个内存队列即可，这样就能保证顺序性。