Kafka -- 幂等生产者 + 事务生产者

简介:   消息交付可靠性保障:Kafka对Producer和Consumer要处理的消息所提供的承诺常见的承诺最多一次(at most once):消息可能会丢失,但绝不会被重复发送至少一次 (at least once):消息不会丢失,但有可能被重复发送精确一次(exactly once):消息不会丢失,也不会被重复发送Kafka默认提供的交付可靠性保障:至少一次只有Broker成功提交 消息且Producer接到Broker的应答才会认为该消息成功发送如果Broker成功提交消息,但Broker的应答没有成功送回Producer端,Producer只能选择重试最多一次Kafka也可以提供最多一

  消息交付可靠性保障:Kafka对Producer和Consumer要处理的消息所提供的承诺常见的承诺最多一次(at most once):消息可能会丢失,但绝不会被重复发送至少一次 (at least once):消息不会丢失,但有可能被重复发送精确一次(exactly once):消息不会丢失,也不会被重复发送Kafka默认提供的交付可靠性保障:至少一次只有Broker成功提交 消息且Producer接到Broker的应答才会认为该消息成功发送如果Broker成功提交消息,但Broker的应答没有成功送回Producer端,Producer只能选择重试最多一次Kafka也可以提供最多一次 交付可靠性保证,只需要让Producer禁止重试 即可,但大部分场景下并不希望出现消息丢失精确一次消息不会丢失,也不会被重复处理,即使Producer端重复发送了相同的消息,Broker端也能自动去重两种机制:幂等性 、事务

  幂等性

  幂等原是数学中的概念:某些操作或者函数能够被执行多次,但每次得到的结果都是不变 的幂等操作:乘1,取整函数;非幂等操作:加1计算机领域在命令式 编程语言(如C)中,如果一个子程序是幂等的,那它必然不能修改系统状态在函数式 编程语言(如Scala、Haskell)中,很多纯函数 天然就是幂等的,不执行任何的Side Effect幂等性的好处:可以安全地重试 任何幂等性操作

  幂等性Producer

  在Kafka中,Producer默认不是幂等的 ,在0.11.0.0 版本引入了幂等性Producer默认情况下 ,Producer向Broker发送数据时,可能会出现同一条消息被发送多次,导致消息重复升级为幂等性Producer

  props.put("enable.idempotence", true)

  props.put(ProducerConfig.ENABLE_IDEMPOTENCE_CONFIG, true)

  基本原理空间换时间 ,在Broker端多保存一些字段当Producer发送了具有相同字段值的消息后,Broker能够自动发现这些重复消息,然后默默丢弃作用范围幂等性Producer只能保证单分区 上的幂等性即只能保证某个主题上的一个分区上不出现重复消息,无法实现二手游戏卖号平台多个分区的幂等性幂等性Producer只能实现单会话 上的幂等性,不能实现跨会话的幂等性会话:Producer进程的一次运行 ,如果重启Producer进程,将丢失幂等性保证如果要实现多分区 或者多会话 的消息无重复,可以采用事务Producer

  事务

  数据库事务提供了ACID 的安全性保障:Atomicity 、Consistency 、Isolation 、DurabilityKafka在0.11 版本开始提供了对事务的支持,目前主要在Read Committed 的隔离级别上做事情保证多条消息原子性地写入目标分区 ,同时也保证Consumer只能看到事务成功提交的消息

  事务Producer

  事务Producer能够保证一批消息原子性地写入多个分区 ,这批消息要么全部写入成功 ,要么全部写入失败事务Producer允许进程重启 ,Producer重启后,Kafka依然保证它们发送的消息的精确一次处理升级为事务Producer

  props.put("enable.idempotence", true)

  props.put("transactional.id", "my-transactional-id")

  record1和record2会被当作一个事务统一提交到Kafka,要么全部提交成功,要么全部写入失败即使写入失败,Kafka也会把它们写入到底层日志 中,即Consumer还是会看到这些消息因此在Consumer端,读取事务Producer发送的消息,需要设置isolation.level 参数read_uncommitted默认值,Consumer能够读取到Kafka写入的任何消息 ,不论事务Producer提交事务还是终止事务read_committedConsumer只会读取到事务Producer成功提交事务写入的消息 ,也能读取到非事务Producer写入的所有消息

  producer.initTransactions();

  try {

  producer.beginTransaction();

  producer.send(new ProducerRecord<>(TOPIC, KEY, VALUE + 1));

  producer.send(new ProducerRecord<>(TOPIC, KEY, VALUE + 2));

  //

  producermitTransaction();

  } catch (KafkaException e) {

  producer.abortTransaction();

  }

  小结

  幂等性Producer和事务Producer都是Kafka社区为了实现精确一次 处理语义所提供的工具,只是作用范围 不同而已幂等性Producer只能保证单分区、单会话 上的消息幂等性;而事务Producer能够保证跨分区、跨会话 的幂等性事务Producer与幂等性Producer相比,性能更差

目录
相关文章
|
1月前
|
消息中间件 Java Kafka
掌握Kafka事务,看这篇就够了
先赞后看,南哥助你Java进阶一大半Kafka事务实际上引入了原子多分区写入的概念,播客画了以下流程图,展示了事务在分区级别如何工作。我是南哥,一个Java学习与进阶的领路人,相信对你通关面试、拿下Offer进入心心念念的公司有所帮助。
掌握Kafka事务,看这篇就够了
|
13天前
|
消息中间件 存储 分布式计算
大数据-72 Kafka 高级特性 稳定性-事务 (概念多枯燥) 定义、概览、组、协调器、流程、中止、失败
大数据-72 Kafka 高级特性 稳定性-事务 (概念多枯燥) 定义、概览、组、协调器、流程、中止、失败
29 4
|
13天前
|
消息中间件 分布式计算 Java
大数据-73 Kafka 高级特性 稳定性-事务 相关配置 事务操作Java 幂等性 仅一次发送
大数据-73 Kafka 高级特性 稳定性-事务 相关配置 事务操作Java 幂等性 仅一次发送
21 2
|
13天前
|
消息中间件 SQL 分布式计算
大数据-76 Kafka 高级特性 稳定性-消费重复 生产者、Broker、消费者 导致的重复消费问题
大数据-76 Kafka 高级特性 稳定性-消费重复 生产者、Broker、消费者 导致的重复消费问题
26 1
|
1月前
|
消息中间件 Kafka
消费kafka不需要设置 压缩协议吗 假如生产者压缩协议是lz4
消费kafka不需要设置 压缩协议吗 假如生产者压缩协议是lz4
|
2月前
|
消息中间件 Java Kafka
Kafka不重复消费的终极秘籍!解锁幂等性、偏移量、去重神器,让你的数据流稳如老狗,告别数据混乱时代!
【8月更文挑战第24天】Apache Kafka作为一款领先的分布式流处理平台,凭借其卓越的高吞吐量与低延迟特性,在大数据处理领域中占据重要地位。然而,在利用Kafka进行数据处理时,如何有效避免重复消费成为众多开发者关注的焦点。本文深入探讨了Kafka中可能出现重复消费的原因,并提出了四种实用的解决方案:利用消息偏移量手动控制消费进度;启用幂等性生产者确保消息不被重复发送;在消费者端实施去重机制;以及借助Kafka的事务支持实现精确的一次性处理。通过这些方法,开发者可根据不同的应用场景灵活选择最适合的策略,从而保障数据处理的准确性和一致性。
159 9
|
2月前
|
消息中间件 Kafka 测试技术
【Azure 事件中心】使用Kafka的性能测试工具(kafka-producer-perf-test)测试生产者发送消息到Azure Event Hub的性能
【Azure 事件中心】使用Kafka的性能测试工具(kafka-producer-perf-test)测试生产者发送消息到Azure Event Hub的性能
|
2月前
|
消息中间件 安全 机器人
【Azure 事件中心】Kafka 生产者发送消息失败,根据失败消息询问机器人得到的分析步骤
【Azure 事件中心】Kafka 生产者发送消息失败,根据失败消息询问机器人得到的分析步骤
|
2月前
|
消息中间件 Java Kafka
Kafka生产者同步和异步的JavaAPI代码演示
Kafka生产者同步和异步的JavaAPI代码演示
39 0
|
6天前
|
消息中间件 存储 运维
为什么说Kafka还不是完美的实时数据通道
【10月更文挑战第19天】Kafka 虽然作为数据通道被广泛应用,但在实时性、数据一致性、性能及管理方面存在局限。数据延迟受消息堆积和分区再平衡影响;数据一致性难以达到恰好一次;性能瓶颈在于网络和磁盘I/O;管理复杂性涉及集群配置与版本升级。