一看就会的kafka多线程顺序消费【内附Demo哦】

Hello，这里是爱 Coding，爱 Hiphop，爱喝点小酒的 AKA 柏炎。

Kafka是一个分布式的，支持多分区、多副本，基于 Zookeeper 的分布式消息流平台，它同时也是一款开源的基于发布订阅模式的消息引擎系统。

kafka如何保证消息不丢失、顺序消费、重复消费？

这三个问题熟不熟悉？是不是在面试的时候经常被问到，在日常工作中也经常碰到？

保证消息不丢失与重复消费其实操作上还是比较简单的。是一些常规的八股文，本文不展开讨论，感兴趣的同学可以给我留言，我单独出一期讲解。

本文将着重与大家讨论Kafka在consumer是单线程与多线程情况下如何保证顺序消费。

我的第一本掘金小册《深入浅出DDD》已经在掘金上线，欢迎大家试读~

一、单线程顺序消费

为了避免有的小伙伴第一次接触顺序消费的概念，我还是先介绍一下顺序消费是个什么东西。

双十一，大量的用户抢在0点下订单。为了用户的友好体验，我们把订单生成逻辑与支付逻辑包装成一个个的MQ消息发送到Kafka中，让kafka积压部分消息，防止瞬间的流量压垮服务。

那么这里的问题就出现了，订单生成与支付都被包装成了消息。这两个消息是有严格的先后顺序的，订单生成逻辑肯定在支付之前。

那么kafka怎么保证它们的顺序呢？

不同topic：

如果支付与订单生成对应不同的topic，你只能在consumer层面去处理了。而因为consumer是分布式的，所以你为了保证顺序消费，只能找一个中间方（比如redis的队列）来维护MQ的顺序，成本太大，逻辑太恶心。

同一个topic：

如果我们把消息发送到同一个topic呢？我们知道一个topic可以对应多个分区，分别对应了多个consumer。其实与不同topic没什么本质上的差别。

同一个topic，同一个分区：

Kafka的消息在分区内是严格有序的。也就是说我们可以把同一笔订单的所有消息，按照生成的顺序一个个发送到同一个topic的同一个分区。那么consumer就能顺序的消费到同一笔订单的消息。

生产者在发送消息时，将消息对应的id进行取模处理，相同的id发送到相同的分区。消息在分区内有序，一个分区对应了一个消费者，保证了消息消费的顺序性。

二、多线程顺序消费

单线程顺序消费已经解决了顺序消费的问题，但是它的扩展能力很差。为了提升消费者的处理速度，但又要保证顺序性，我们只能横向扩展分区数，增加消费者。

这就意味着需要加机器来增加你的系统处理能力。

emmmÿ