14 | 幂等生产者和事务生产者是一回事吗？
该思维导图由 AI 生成，仅供参考
荧光笔
直线
曲线- 深入了解
- 翻译
- 解释
- 总结
Kafka消息交付可靠性保障及精确处理一次语义的实现是本文的主题。文章首先介绍了Kafka的消息交付可靠性保障的三种承诺：最多一次、至少一次和精确一次。随后详细讨论了幂等性和事务这两种机制在实现精确一次消息交付方面的作用。幂等性Producer保证消息不重复发送，但仅限于单分区和单会话；而事务型Producer实现了多分区和多会话上的消息无重复发送，同时保证消息的原子性写入。通过幂等性和事务这两种机制，Kafka实现了精确一次的消息交付语义，确保消息不会丢失，也不会被重复发送。总的来说，幂等性Producer和事务型Producer是Kafka社区为实现精确一次处理语义提供的工具，只是它们的作用范围不同。事务型Producer能够保证跨分区、跨会话间的幂等性，但性能较差，在实际使用中需要仔细评估引入事务的开销。
《Kafka 核心技术与实战》，新⼈⾸单¥68
全部留言(113)
- 最新
- 精选
October我所理解的kafka事务是这样的：生产者的事务能够保证一条消息仅仅会保存在kafka的某一个分区上，不会出现在多个分区上，另外，能够保证多条消息原子性的发送到多个分区。也就是说它只保证了从producer端到broker端消息不丢失不重复。但对于consumer端，由于偏移量的提交和消息处理的顺序有前有后，依然可能导致重复消费或者消息丢失消费，如果要实现消费者消费的精确一次，还需要通过额外机制在消费端实现偏移量提交和消息消费的事务处理。不知道自己理解的对不对，希望老师指正。作者回复: 嗯嗯，我觉得很有道理：）
2019-07-04235
dream老师，请问一下，事务型 Producer 可以实现一组消息要么全部写入成功，要么全部失败，但是事务型 Producer 是具体怎么实现多分区以及多会话上的消息无重复的呢？作者回复: 主要的机制是两阶段提交（2PC）。引入了事务协调器的组件帮助完成分布式事务
2019-07-04428
风中花我一直认为事务，不到必须时是不用得东西，那么我想知道，胡老师实际中，你们有用到过吗，在一些什么场景下使用？老师可以简单说下吗，谢谢作者回复: 我们没有使用。事务更多用在Kafka Streams中。如果要实现流处理中的精确一次语义，事务是不可少的。
2019-07-0423
涛老师，kafka中的事务提交异常，broker端的数据还是会写入日志，相当于只是记录一下失败状态，在消费端通过隔离级别，来过滤掉出这部分消息，不进行消费。为什么事务异常了，还要将数据写入日志呢？直接删除掉不好吗？像DB那样。作者回复: Kafka broker基本上还是保持append-only的日志型风格，不做删除处理
2019-10-0616
Kim老师，有个地方很困惑，这句话“实际上即使写入失败，Kafka 也会把它们写入到底层的日志中，也就是说 Consumer 还是会看到这些消息”这是什么意思？明明写入都失败了，为什么还会写到底层的commit log中呢？那这里的写入失败是指写入磁盘失败么？麻烦老师解答一下，谢谢~~作者回复: 这里的写入失败是指事务失败，可能没有说太清楚。如果事务失败中止了，Kafka没法向数据库那样执行回滚，写入的日志也只能继续“躺在”日志中了，但是Kafka依赖于LSO等机制来设定一个事务型Consumer的可见范围，保证事务的准确性
2020-04-09211
冉冉想问下老师一个关于消费者的问题，如果一个消费者组里有两个消费者c1，c2，一个topic有两个分区p1，p2，那c1永远从p1收消息，而不会收到生产者发到p2的消息对吗？作者回复: hmmm.... 应该这么来说：从Kafka设计的角度，不是永远的关系，c1理论上可以收到p2的消息，只要发生了rebalance。但实际使用过程中，一旦你的group确定了分配策略，其实这种分配关系也就是确定的了。特别是对于你这个场景，无论发生多少次rebalance，p1应该都会被分配给c1。当然我说的是c1,c2都运行的情况下，如果c2挂了，c1肯定能收到p2的消息
2020-04-2310
妥协不启用幂等也可以保证同分区下无消息乱序的。——消息发送失败重发时，在broker端不会导致收到的顺序，和producer端发送顺序不一致吗？如果是的话，是类似TCP那种保证有序的机制吗？作者回复: 需要配合参数max.in.flight.requests.per.connection = 1来实现。这样producer会等待之前请求的消息发送成功才会发送下一个，从而不会乱序
2020-02-2310
南山老师，事务型producer不会重复发送消息吗？如果发送的这一批到broker了，但是broker返回的确认消息producer没有收到，再次尝试，broker会去重吗？或者consumer端会去重啊？作者回复: producer端可能发送重复消息，broker端有一套机制来去重（幂等性依赖seq number机制，事务依赖各种marker来标记）
2019-11-099
Liamretry的话producer会保证发送到同一个分区吧，不然幂等性就没法保证了作者回复: 是的，会保证
2019-07-047- 妥协重启之后标识producer的PID就变化了，broker就不认识了——这个是幂等性的另一个限制条件，无法实现夸会话的幂等性。我理解的是：一个幂等性的producer，只保证单分区的幂等性，而producer的消息会发给一个主题的多个分区，每个单分区都保证幂等性，其实就是实现了多分区的幂等性，只是无法实现跨会话的幂等性，不知道理解的对不对？
作者回复: 嗯，很有道理：）
2020-03-1235
