处理 Kafka 的恰好一次处理边缘情况

Question

各位， 尝试使用 Kafka 进行 POC 来处理消息，以实现绝对只需要一次处理的实现。示例：as a payment system, process a credit card transaction only once

我们应该防止哪些边缘情况？

here 涵盖的一个故障场景是：

1.) 如果消费者失败，并且没有提交它已读取特定偏移量，则将再次读取该消息。

假设消费者住在 Kubernetes pod 中，其中一台主机离线。由于底层硬件问题，在 Pod 消失之前，我们可能会处理已处理但未在 Kafka 中标记为已处理的消息。我是否正确理解了这个错误场景？

在考虑 Kafka 只进行一次处理时，我们是否需要在生产者/消费者方面充分了解其他故障场景？

谢谢！

Answer 1

我将基本上重复并扩展我给here的答案：

一些情况可能会导致重复：

1. 消费者只定期检查他们的位置。消费者崩溃可能会导致重复处理某些范围或记录
2. 生产者有客户端超时。这意味着生产者可能认为请求超时并在代理端实际成功时重新传输。
3. 如果您在 kafka 集群之间镜像数据，这通常是通过某种生产者 + 消费者对来完成的，这可能会导致更多重复。

还有一些最终会导致数据丢失的情况 - 查找“不干净的领导者选举”（禁用该交易与可用性）。

另外 - kafka “exactly once” 配置只有在你所有的输入、输出和副作用都发生在同一个 kafka 集群上时才有效。这通常使得它在现实生活中的用途有限。

您可以尝试使用一些 kafka 功能来降低发生这种情况的可能性：

1. 在生产者配置中将 enable.idempotence 设置为 true（请参阅 https://kafka.apache.org/documentation/#producerconfigs） - 会产生一些开销
2. 在生成时使用事务 - 会产生开销并增加延迟
3. 在生产者上设置 transactional.id，以防跨机器故障转移 - 大规模管理变得复杂
4. 在消费者上将isolation.level 设置为read_committed - 增加延迟（需要结合上述2 完成）
5. 缩短消费者的 auto.commit.interval.ms - 只是减少重复窗口，并不能真正解决任何问题。以非常低的值产生开销。

我不得不说，作为过去几年一直在维护 非常 大型 kafka 安装的人，我永远不会使用依赖 kafka 进行核心交易处理的银行......