Apache Kafka Exactly Once 事务 id 如何影响新的 fetch request producer fencing 方法答案

【问题标题】：How Apache Kafka Exactly Once transaction id impact on the new fetch request producer fencing approachApache Kafka Exactly Once 事务 id 如何影响新的 fetch request producer fencing 方法
【发布时间】：2021-07-16 04:40:28
【问题描述】：

在早期版本的 Kafka 中，事务 ID 和主题分区之间的静态映射应该在消费者组不匹配期间具有一次性语义，因此事务 ID 有可能获得不同的主题分区。

为了避免这种情况 KIP-447: Producer scalability for exactly once semantics 已实施，我从 KIP-477 中了解到，旧生产者在新 API(sendOffsetToProdcuer) 的帮助下使用 fetch offset 调用进行了防护，因此 transactio.id 不用于围栏。

但我的疑问是，

仍然是事务生产者期望 transaction.id 我应该如何为最新的 Kafka 版本选择这个值？
transaction.id 应该有一个与分区的静态映射，fetch offset fencing 只在消费者组再平衡时生效？
这个值对最新版本无效吗？

请帮我解决这个问题，我正在尝试了解 Kafka EoS 并在生产系统中实现它。

【问题讨论】：

标签： apache-kafka spring-kafka confluent-platform exactly-once

【解决方案1】：

既然你用spring-kafka 标记了它，我假设你正在使用它； transactional.id 现在对于每个实例都可以不同（因为以前仅生产者的事务需要它）。不再需要将 id 绑定到组/主题/分区，并且需要的生产者数量要少得多。

见https://docs.spring.io/spring-kafka/docs/current/reference/html/#exactly-once

代理需要是 2.5 或更高版本。

【讨论】：

我正在使用 spring-kafka 但试图了解 EOS 内部结构。在生产者的 beginTransaction 步骤之前，旧生产者被隔离，但在 fetchOffset 隔离机制中，消费者元数据使用 sendOffsetsToTransaction 发送，所以生产者隔离到底在哪里发生在新方法中。
KIP 解释得很好；如果您还有其他问题，我建议您在 Apache Kafka 邮件列表中提问。