如何在 Kubernetes（仅生产者端事务）设置中选择 Kafka transactional.id

Question

我有一个 Kafka 包装器库，它仅在生产端使用事务。图书馆不覆盖消费者。制作者发布到多个主题。目标是实现交易性。因此，生产应该要么成功，这意味着每个主题中应该只有一次写入的消息副本，要么失败，这意味着消息没有写入任何主题。该库的用户是在 Kubernetes Pod 上运行的应用程序。因此，Pod 可能会失败或频繁重新启动。此外，发送消息时不会显式设置分区。

我的问题是，我应该如何为生产者选择 transactional.id？我的第一个想法是在对象启动时简单地选择 UUID，并将 transaction.timeout.ms 设置为某个合理的时间（几秒钟）。这样，如果生产者由于 Pod 重新启动而终止，消费者不会永远锁定事务。

这个策略有什么缺陷吗？有没有更聪明的方法来做到这一点？另外，我不能向图书馆用户索要某种 ID。

Answer 1

UUID 可以在您的库中使用来为您的生产者生成交易 ID。我不太确定你的意思：这样，如果生产者由于 Pod 重新启动而终止，消费者就不会永远锁定事务。

消费者永远不会真正“陷入困境”。假设生产者在向一个主题写入消息后出现故障（因此事务尚未提交），那么消费者将按以下方式之一行事：

• 如果isolation.level设置为read_committed，消费者将永远不会处理该消息（因为该消息未提交）。它仍然会读取下一条提交的消息。
• 如果isolation.level设置为read_uncommitted，则消息将被读取并处理（首先就违背了事务的目的）。