2019-09-08幂等性producer和事务型producer实现原理都没有涉及，这篇有点太肤浅了 23
2019-07-04老师，请问一下，事务型 Producer 可以实现一组消息要么全部写入成功，要么全部失败，但是事务型 Producer 是具体怎么实现多分区以及多会话上的消息无重复的呢？作者回复: 主要的机制是两阶段提交（2PC）。引入了事务协调器的组件帮助完成分布式事务
14
2019-07-26研究了一下kafka的设计文档，基本搞清楚了幂等和事务消息，一些理解，https://www.jianshu.com/p/f77ade3f41fd， 欢迎大家一起交流。 1 10
2019-07-09文中提到了幂等性，希望能够讲解下幂等性原理，如何实现，这样大家才能明白为何幂等性无法保证：跨回话、跨分区 6
2019-08-02版本0.11.0.2，设置transactional.id并开启事务后，须同时保证retries>1 5
2019-07-04我一直认为事务，不到必须时是不用得东西，那么我想知道，胡老师实际中，你们有用到过吗，在一些什么场景下使用？老师可以简单说下吗，谢谢作者回复: 我们没有使用。事务更多用在Kafka Streams中。如果要实现流处理中的精确一次语义，事务是不可少的。
5
2019-07-04我所理解的kafka事务是这样的：生产者的事务能够保证一条消息仅仅会保存在kafka的某一个分区上，不会出现在多个分区上，另外，能够保证多条消息原子性的发送到多个分区。也就是说它只保证了从producer端到broker端消息不丢失不重复。但对于consumer端，由于偏移量的提交和消息处理的顺序有前有后，依然可能导致重复消费或者消息丢失消费，如果要实现消费者消费的精确一次，还需要通过额外机制在消费端实现偏移量提交和消息消费的事务处理。不知道自己理解的对不对，希望老师指正。作者回复: 嗯嗯，我觉得很有道理：）
3
2019-07-05老师，你好
幂等性为什么只保证单分区有效？是因为下一次消息重试指不定发送到哪个分区么。如果这样的话是不是可以采用按消息键保序的方式？这样重试消息还发送到同一个分区。作者回复: 重启之后标识producer的PID就变化了，broker就不认识了。要想认识就要让broker和producer做更多的事，也就是事务机制做的那些事。
重试还是发送到同一个分区 2
2019-07-04实现上可以用kafka的幂等性来保证单分区单会话的精准一次语义，如果是一批消息，可以路由到同一个分区 2
2019-11-14对于单会话单分区幂等性～可以使用key分区策略，来实现多分区单会话幂等性。 1
2019-10-06老师，kafka中的事务提交异常，broker端的数据还是会写入日志，相当于只是记录一下失败状态，在消费端通过隔离级别，来过滤掉出这部分消息，不进行消费。为什么事务异常了，还要将数据写入日志呢？直接删除掉不好吗？像DB那样。作者回复: Kafka broker基本上还是保持append-only的日志型风格，不做删除处理
1
2019-10-06个人觉得由消费者来根据自身需求来保证幂等性要更好 1
2019-08-28事务还有用 冥等生产者没什么用，反正消费端都是有可能重复消费的，业务上必须做去重处理作者回复: Kafka Streams依靠幂等producer和事务机制来保证EOS
1 1
2019-07-27老师好，对这段话不太了解“首先，它只能保证单分区上的幂等性，即一个幂等性 Producer 能够保证某个主题的一个分区上不出现重复消息，它无法实现多个分区的幂等性。” 其中，幂灯性producer无法实现对个分区的的幂等性能否举个具体的例子说明？谢谢老师作者回复: 对于实现多个分区的原子性写入，幂等性producer就做不到
1
2019-07-08老师我对今天的内容还是有些不理解，希望老师帮我解答下
1、幂等性是通过pid+seq来实现的，我看一些讲解说seq是针对分区级别的，假如目前topic 有两个分区 B和C，这时候我对该topic连续发送两条消息（轮询方式），那么B和C的seq是连续的还是相互独立的，即B-seq=1,C-seq=1 还是B-seq=1,C-seq=2
2、如果消息发送失败，在进行retry的时候 还是会向同一个分区发送吗？还是选择新的分区
3、看老师你发的事务代码，同时发两条消息，如果设置了幂等性理论上这两条消息应该在两个分区都能实现exactly once才对啊 ，都有自动重发的机制了为什么还要开启事务，是因为在会重试超过次数就放弃重试吗展开作者回复: 如果涉及多个分区的原子写入，幂等producer就无法实现了，只能依靠事务
1 1
2019-07-05老师请教个问题啊，我们在一个生产环境是日志入kafka，然后读取kafka的数据入到es里面，由于数据比较多，所以入到kafka的数据可能要过半天到一天才可以处理完，结果发现一个很奇怪的现象就是kafka的入的数据越快，那么入es的速度也越快，本来怀疑是kafka数据在cache里面所以快的，但是我们的数据延迟了很久，不太可能在cache，而且通过读kafka的程序日志分析，读kafka环节一直很快，只是入es的时间有快又慢，这个可能是什么问题那？作者回复: 如果consumer能够读取page cache中的数据而不是要去磁盘执行物理读，那么可以用上zero copy，速度应该是很快的。你可以看下你的consumer消费时broker的物理读IO，如果很低，大概率走的是page cache。另外如果读kafka很快，es忽高忽低，那是不是应该查一下ES的写入？
1 1- 2019-07-04一个幂等性 Producer 能够保证某个主题的一个分区上不出现重复消息，也就是说同一条消息可能出现在不同的分区上，可是producer端没有收到broker的ack，就会重试，重试应该能保证同一条消息分区是不会改变的，为什么这条消息会出现在其他分区呢。
作者回复: “也就是说同一条消息可能出现在不同的分区上” --- 不可能。。。。。。
2 1 
2020-01-27props.put(“enable.idempotence”, ture)
->
props.put(“enable.idempotence”, true)作者回复: Thanks for responding:)
2020-01-23胡老师，这一小节确实有可扩展的空间。后面有机会麻烦讲一下kakfa的事务原理哈作者回复: 说来有点话长了，您具体想知道事务的那些方面呢？
2020-01-16老师，看到producer的api有个sendOffsetsToTransaction，这个要怎么理解？producer怎么和位移扯上关系了，不是消费者消费后才有位移吗作者回复: 这个是事务型producer需要用到的API。当启用事务时，producer需要记录内部事务主题的位移，这个API就是用来做这个事情的~