作者回复: 主要的机制是两阶段提交(2PC)。引入了事务协调器的组件帮助完成分布式事务
作者回复: 我们没有使用。事务更多用在Kafka Streams中。如果要实现流处理中的精确一次语义,事务是不可少的。
作者回复: 嗯嗯,我觉得很有道理:)
作者回复: 重启之后标识producer的PID就变化了,broker就不认识了。要想认识就要让broker和producer做更多的事,也就是事务机制做的那些事。
重试还是发送到同一个分区
作者回复: Kafka broker基本上还是保持append-only的日志型风格,不做删除处理
作者回复: Kafka Streams依靠幂等producer和事务机制来保证EOS
作者回复: 对于实现多个分区的原子性写入,幂等性producer就做不到
作者回复: 如果涉及多个分区的原子写入,幂等producer就无法实现了,只能依靠事务
作者回复: 如果consumer能够读取page cache中的数据而不是要去磁盘执行物理读,那么可以用上zero copy,速度应该是很快的。你可以看下你的consumer消费时broker的物理读IO,如果很低,大概率走的是page cache。另外如果读kafka很快,es忽高忽低,那是不是应该查一下ES的写入?
作者回复: “也就是说同一条消息可能出现在不同的分区上” --- 不可能。。。。。。
作者回复: 看上去是个已知的Kafka bug,升级到新版本试试吧
作者回复: producer端可能发送重复消息,broker端有一套机制来去重(幂等性依赖seq number机制,事务依赖各种marker来标记)
作者回复: 不启用幂等也可以保证同分区下无消息乱序的。