如何保证kafka消费的顺序性

在Kafka中Partition(分区)是真正保存消息的地方，发送的消息都存放在这里。Partition(分区)又存在于Topic（主题）中，并且一个Topic（主题）可以指定多个Partition(分区)。

在Kafka中，只保证Partition(分区)内有序，不保证Topic所有分区都是有序的。

所以 Kafka 要保证消息的消费顺序，可以有2种方法：

一、1个Topic（主题）只创建1个Partition(分区)，这样生产者的所有数据都发送到了一个Partition(分区)，保证了消息的消费顺序。

二、生产者在发送消息的时候指定要发送到哪个Partition(分区)。

怎么指定呢？我们需要将 producer 发送的数据封装成一个 ProducerRecord 对象。

（1）指明 partition 的情况下，直接将指明的值直接作为 partiton 值；

（2）没有指明 partition 值但有 key 的情况下，将 key 的 hash 值与 topic 的 partition数进行取余得到 partition 值；

 在Producer往Kafka插入数据时，控制同一Key分发到同一Partition，并且设置参数max.in.flight.requests.per.connection=1，也即同一个链接只能发送一条消息，如此便可严格保证Kafka消息的顺序

（3）既没有 partition 值又没有 key 值的情况下，第一次调用时随机生成一个整数（后

面每次调用在这个整数上自增），将这个值与 topic 可用的 partition 总数取余得到 partition

值，也就是常说的 round-robin 算法。

那么问题来了：在1个topic中，有3个partition，那么如何保证数据的消费？

1、如顺序消费中的 "第①点" 和 "Kafka 要保证消息的消费顺序第二个方法" 说明，生产者在写的时候，可以指定一个 key，比如说我们指定了某个订单 id 作为 key，那么这个订单相关的数据，一定会被分发到同一个 partition 中去，而且这个 partition 中的数据一定是有顺序的。

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

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

解决方案：
写N个queue，将具有相同key的数据都存储在同一个queue，然后对于N个线程，每个线程分别消费一个queue即可。

注：在单线程中，一个 topic，一个 partition，一个 consumer，内部单线程消费，这样的状态数据消费是有序的。但由于单线程吞吐量太低，在数据庞大的实际场景很少采用。

但是以上消费线程模型，存在一个问题：

在消费过程中，如果 Kafka 消费组发生重平衡，此时的分区被分配给其它消费组了，如果拉取回来的消息没有被消费，虽然 Kakfa 可以实现 ConsumerRebalanceListener 接口，在新一轮重平衡前主动提交消费偏移量，但这貌似解决不了未消费的消息被打乱顺序的可能性？

因此在消费前，还需要主动进行判断此分区是否被分配给其它消费者处理，并且还需要锁定该分区在消费当中不能被分配到其它消费者中（但 kafka 目前做不到这一点）。

参考 RocketMQ 的做法：

在消费前主动调用 ProcessQueue#isDropped 方法判断队列是否已过期，并且对该队列进行加锁处理（向 broker 端请求该队列加锁）。

RocketMQ

RocketMQ 不像 Kafka 那么“原生”，RocketMQ 早已为你准备好了你的需求，它本身的消费模型就是单 consumer 实例 + 多 worker 线程模型，有兴趣的小伙伴可以从以下方法观摩 RocketMQ 的消费逻辑：

org.apache.rocketmq.client.impl.consumer.PullMessageService#run

RocketMQ 会为每个队列分配一个 PullRequest，并将其放入 pullRequestQueue，PullMessageService 线程会不断轮询从 pullRequestQueue 中取出 PullRequest 去拉取消息，接着将拉取到的消息给到 ConsumeMessageService 处理，ConsumeMessageService 有两个子接口：

// 并发消息消费逻辑实现类org.apache.rocketmq.client.impl.consumer.ConsumeMessageConcurrentlyService;// 顺序消息消费逻辑实现类org.apache.rocketmq.client.impl.consumer.ConsumeMessageOrderlyService;

其中，ConsumeMessageConcurrentlyService 内部有一个线程池，用于并发消费，同样地，如果需要顺序消费，那么 RocketMQ 提供了 ConsumeMessageOrderlyService 类进行顺序消息消费处理。

经过对 Kafka 消费线程模型的思考之后，从 ConsumeMessageOrderlyService 源码中能够看出 RocketMQ 能够实现局部消费顺序，我认为主要有以下两点：

1）RocketMQ 会为每个消息队列建一个对象锁，这样只要线程池中有该消息队列在处理，则需等待处理完才能进行下一次消费，保证在当前 Consumer 内，同一队列的消息进行串行消费。

2）向 Broker 端请求锁定当前顺序消费的队列，防止在消费过程中被分配给其它消费者处理从而打乱消费顺序

总结

1）多分区的情况下：

如果想要保证 Kafka 在消费时要保证消费的顺序性，可以使用每个线程维护一个 KafkaConsumer 实例的消费线程模型，并且是一条一条地去拉取消息并进行消费（防止重平衡时有可能打乱消费顺序）。（备注：每个 KafkaConsumer 会负责固定的分区，因此无法提升单个分区的消费能力，如果一个主题分区数量很多，只能通过增加 KafkaConsumer 实例提高消费能力，这样一来线程数量过多，导致项目 Socket 连接开销巨大，项目中一般不用该线程模型去消费。）

对于能容忍消息短暂乱序的业务（话说回来， Kafka 集群也不能保证严格的消息顺序），可以使用单 KafkaConsumer 实例 + 多 worker 线程 + 一条线程对应一个阻塞队列消费线程模型(以上两图就是对此消费线程模型的解释)。

1）单分区的情况下：

由于单分区不存在重平衡问题，以上所提到的线程模型都可以保证消费的顺序性。

另外如果是 RocketMQ，使用 MessageListenerOrderly 监听消费可保证消息消费顺序。

很多人也有这个疑问：既然 Kafka 和 RocketMQ 都不能保证严格的顺序消息，那么顺序消费还有意义吗？

一般来说普通的的顺序消息能够满足大部分业务场景，如果业务能够容忍集群异常状态下消息短暂不一致的情况，则不需要严格的顺序消息。