谈谈 Kafka 的幂等性 Producer

使用消息队列,我们肯定希望不丢消息,也就是消息队列组件,需要保证消息的可靠交付。消息交付的可靠性保障,有以下三种承诺:

  • 最多一次(at most once):消息可能会丢失,但绝不会被重复发送。
  • 至少一次(at least once):消息不会丢失,但有可能被重复发送。
  • 精确一次(exactly once):消息不会丢失,也不会被重复发送。

默认是一般是 至少一次,也就是 Broker 收到并成功提交消息,并且 Producer 成功应答才会认为消息已经发送。

某些情况下,比如网络波动等,导致应答没有成功送达,会导致 Producer 重试,从而导致消息的重复发送。

这就要提到主角------幂等性 Producer 了。

幂等性,比如数学中的乘法运算,乘以 1 就是一个幂等操作。因为不管执行多少次乘法,结果都是一样的。

幂等性 Producer 就是在向 Broker 发送数据时,可以避免同个分区下的消息重复。

开启方式仅需指定 enable.idempotence 为 true!

但是!

有个很重要的一点,它针对的是单个分区下的幂等,而且是单个会话内的幂等,也就是说,如果进程重启,就没办法保证幂等性了。

而幂等性的实现原理,就得提到 ProducerID 和 SequenceNumber 了。

  • ProducerID:Producer 初始化会被分配一个唯一标识,对客户端无感知,重启会发生变化;
  • SequenceNumber:对于每个主题和分区,都对应一个从 0 开始单调递增的 SequenceNumber 值,Broker 也会存储。

判断重复的逻辑,原理就很简单了:

通过 ProducerID 和 SequenceNumber,去 Broker 查询队列 ProducerStateEntry.Queue(默认队列长度为 5)是否存在:

  • 如果 Producer SequenceNumber == Broker SequenceNumber + 1,接收消息;
  • 如果 Producer SequenceNumber == 0 && Broker SequenceNumber == MaxInt,接收消息(刚初始化);
  • 否则,就是重复了,拒绝接收。

由此看出,ProducerID 和 SequenceNumber 可以避免消息的重复发送,也避免消息乱序(因为 SequenceNumber 单调递增)。

做到幂等性,也就意味着可以安全重试任何操作。从而做到了消息的可靠传输。

然而,还有个很重要的一点,就是上面说的,上面讲的都是分区下的幂等,多个分区的幂等性,需要通过 事务 来解决。

限于篇幅,今天先记录到这里,事务的待我好好研究下再写哈哈!最后,祝大家新年快乐!


文章来源于本人博客,发布于 2023-01-01,原文链接:https://imlht.com/archives/414/

相关推荐
Thanks_ks9 小时前
Cookie 和 Session 到底是什么关系——登录态是怎么维持的
分布式·http·jwt·cookie·session·后端开发·登录态
千里达景区票务系统9 小时前
消息队列选型对比:RabbitMQ vs RocketMQ vs Kafka
kafka·消息队列·rabbitmq·rocketmq
车载中间件通信11 小时前
[TC8测试]TCP_FLAGS_PROCESSING_06
数据库·网络协议·tcp/ip·中间件·tc8
Sayai11 小时前
Kafka 跨数据中心日志同步实战:MirrorMaker 2 选型对比 + Flink 中继任务落地(双中心互备与消费者组隔离避坑)
大数据·运维·分布式·flink·kafka·消息队列·高可用
jianjinwssy13 小时前
从零设计一个 Agent 安全沙箱:Docker 隔离、三级风控与 Kafka 审计
人工智能·docker·kafka
CodeGL1 天前
开源的分布式任务调度平台:XXL-Job
分布式·开源
一条泥憨鱼1 天前
【Kafka】零基础学习教程
java·分布式·学习·kafka
9624561 天前
补打一条卡,为什么要从前一天重新算:人工补录与实时重算业务复盘
java·mysql·kafka
kingx31 天前
网络安全事件应急响应:X集团 WebServer 入侵溯源与处置
中间件·web·应急响应·取证·恶意样本
贾伟康1 天前
【共创稿事节】HarmonyOS 7.0 HiTraceChain分布式调用链:从接入到生产验证
分布式·harmonyos·可观测性·调用链·hitracechain