Kafka消息队列怎么保证exactlyOnce,怎么实现顺序消费

36 篇文章 1 订阅
20 篇文章 3 订阅

“Kafka消息队列怎么保证exactlyOnce,怎么实现顺序消费”

这个问题,难倒了很多工作5年以上的程序员。

而且这个问题的面试频率也非常高,建议大家收藏反复观看。

另外,我把这个问题的回答整理到了50万字的大厂面试指南里面,大家可以在文章尾端领取。

问题解析

在回答这个问题之前,先来了解一下Kafka的运行机制。

当我们向某个Topic发送消息的时候,在Kafka的Broker上,会通过Partition分区的机制来实现消息的物理存储。

一个Topic可以有多个Partition,相当于把一个Topic里面的N个消息数据进行分片存储。

消费端去消费消息的时候,会从指定的Partition中去获取。

在同一个消费组中,一个消费者可以消费多个Partition中的数据。但是消费者的数量只能小于或者等于Partition分区数量。

image-20230413130121124

理解了Kafka的工作机制以后,再来理解一下exactlyOnce的意思,在MQ的消息投递的语义有三种:

  • At Most Once: 消息投递至多一次,可能会丢但不会出现重复。

  • At Least Once: 消息投递至少一次,可能会出现重复但不会丢。

  • Exactly Once: 消息投递正好一次,不会出现重复也不会丢。

所以,要回答好这个问题,必须要从上面这两个角度去切入,下面看看这个问题的回答。

问题答案

首先我先回答Kafka如何保证ExactlyOnce。

准确来说,目前市面上的MQ产品,基本上都没有提供Exactly Once语义的实现。

我们只能通过一些其他手段来达到Exactly Once的效果。

也就是确保生产者只发送一次,消费端只接受一次

  1. 生产者可以采用事物消息的方式,事务可以支持多分区的数据完整性,原子性。

    并且支持跨会话的exactly once处理语义,即使producer宕机重启,依旧能保证数据只处理一次

    开启事务首先需要开启幂等性,即设置enable.idempotence为true。然后对producer消息发送做事务控制。

    如果出现导致生产者重试的错误,同样的消息,仍由同样的生产者发送多次,这个消息只被写到 Kafka broker 的日志中一次

  2. 虽然生产者能保证在Kafka broker上只记录唯一一条消息,但是由于网络延迟的存在,有可能会导致Broker在投递消息给消费者的时候,触发重试导致投递多次。

    所以消费端,可以采用幂等性的机制来避免重试带来的重复消费问题。

其次,关于实现顺序消费问题。

在Kafka里面,每个Partition分区的消息本身就是按照顺序存储的。

所以只需要针对Topic设置一个Partition,这样就保证了所有消息都写入到这一个Partition中。

而消费者这边只需要消费这个分区,就可以实现消息的顺序消费处理。

总结

大家知道怎么回答了吗?

如果你喜欢我的作品,记得点赞收藏加关注哦!!!

另外,我将所有Java面试系列制作成了完整的面试文档。它的便捷之处在于,可以通过检索的方式,找到你想要的面试题,目前已经更新350期,总计超过35W字!

【想领取面试文档的小伙伴可以点击文章底部名片无套路免费赠送给大家!】

需要高手面试文档面试文档的小伙伴可以扫描下方二维码
↓↓↓↓↓↓↓↓↓↓↓↓↓

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

跟着Mic学架构

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值