“Kafka消息队列怎么保证exactlyOnce,怎么实现顺序消费”
这个问题,难倒了很多工作5年以上的程序员。
而且这个问题的面试频率也非常高,建议大家收藏反复观看。
另外,我把这个问题的回答整理到了50万字的大厂面试指南里面,大家可以在文章尾端领取。
问题解析
在回答这个问题之前,先来了解一下Kafka的运行机制。
当我们向某个Topic发送消息的时候,在Kafka的Broker上,会通过Partition分区的机制来实现消息的物理存储。
一个Topic可以有多个Partition,相当于把一个Topic里面的N个消息数据进行分片存储。
消费端去消费消息的时候,会从指定的Partition中去获取。
在同一个消费组中,一个消费者可以消费多个Partition中的数据。但是消费者的数量只能小于或者等于Partition分区数量。
理解了Kafka的工作机制以后,再来理解一下exactlyOnce的意思,在MQ的消息投递的语义有三种:
-
At Most Once: 消息投递至多一次,可能会丢但不会出现重复。
-
At Least Once: 消息投递至少一次,可能会出现重复但不会丢。
-
Exactly Once: 消息投递正好一次,不会出现重复也不会丢。
所以,要回答好这个问题,必须要从上面这两个角度去切入,下面看看这个问题的回答。
问题答案
首先我先回答Kafka如何保证ExactlyOnce。
准确来说,目前市面上的MQ产品,基本上都没有提供Exactly Once语义的实现。
我们只能通过一些其他手段来达到Exactly Once的效果。
也就是确保生产者只发送一次,消费端只接受一次
-
生产者可以采用事物消息的方式,事务可以支持多分区的数据完整性,原子性。
并且支持跨会话的exactly once处理语义,即使producer宕机重启,依旧能保证数据只处理一次
开启事务首先需要开启幂等性,即设置
enable.idempotence
为true。然后对producer消息发送做事务控制。如果出现导致生产者重试的错误,同样的消息,仍由同样的生产者发送多次,这个消息只被写到 Kafka broker 的日志中一次
-
虽然生产者能保证在Kafka broker上只记录唯一一条消息,但是由于网络延迟的存在,有可能会导致Broker在投递消息给消费者的时候,触发重试导致投递多次。
所以消费端,可以采用幂等性的机制来避免重试带来的重复消费问题。
其次,关于实现顺序消费问题。
在Kafka里面,每个Partition分区的消息本身就是按照顺序存储的。
所以只需要针对Topic设置一个Partition,这样就保证了所有消息都写入到这一个Partition中。
而消费者这边只需要消费这个分区,就可以实现消息的顺序消费处理。
总结
大家知道怎么回答了吗?
如果你喜欢我的作品,记得点赞收藏加关注哦!!!
另外,我将所有Java面试系列制作成了完整的面试文档。它的便捷之处在于,可以通过检索的方式,找到你想要的面试题,目前已经更新350期,总计超过35W字!