gpt4 book ai didi

java - 'exactly once' 是否仅适用于流(主题 1 -> 应用程序 -> 主题 2)?

转载 作者:行者123 更新时间:2023-11-30 10:04:02 24 4
gpt4 key购买 nike

我有一个架构,其中有两个独立的应用程序。原始来源是一个sql数据库。 App1 监听 CDC 表以跟踪对该数据库中表的更改、规范化和序列化这些更改。它获取这些序列化消息并将它们发送到 Kafka 主题。 App2 监听该主题,将消息调整为不同的格式,并通过 HTTP 将这些调整后的消息发送到各自的目的地。

所以我们的流式架构看起来像:

SQL (CDC event) -> App1 ( normalizes events) -> Kafka -> App2 (adapts events to endpoints) -> various endpoints

我们希望在出现故障时添加错误处理,并且不能容忍重复事件、丢失事件或顺序更改。鉴于上述架构,我们真正关心的是 exactly-once 适用于从 App1 到 App2(我们独立的生产者和消费者)的消息

我正在阅读的所有内容以及我发现的有关事务性 API 的每个示例都指向“流”。看起来 Kafka streaming api 适用于从 Kafka 主题获取输入、进行处理并将其输出到另一个 Kafka 主题的单个应用程序,这似乎不适用于我们对 Kafka 的使用。这是 Confluent's docs 的摘录:

Now, stream processing is nothing but a read-process-write operation on a Kafka topic; a consumer reads messages from a Kafka topic, some processing logic transforms those messages or modifies state maintained by the processor, and a producer writes the resulting messages to another Kafka topic. Exactly once stream processing is simply the ability to execute a read-process-write operation exactly one time. In this case, “getting the right answer” means not missing any input messages or producing any duplicate output. This is the behavior users expect from an exactly once stream processor.

我正在努力思考如何将 exactly-once 与我们的 Kafka 主题一起使用,或者 Kafka 的 exactly-once 是否甚至是为非“流式”用例构建的。我们必须构建自己的重复数据删除和容错功能吗?

最佳答案

如果您使用的是 Kafka 的 Streams API(或其他支持使用 Kafka 进行精确一次处理的工具),那么 Kafka 的精确一次语义 (EOS) 涵盖在所有应用程序中:

topic A --> App 1 --> topic B --> App 2 --> topic C

在您的用例中,一个问题是初始 CDC 步骤是否也支持 EOS。换句话说,您必须问这样一个问题:涉及哪些步骤,EOS 涵盖所有步骤吗?

在以下示例中,如果(且仅当)初始 CDC 步骤也像数据流的其余部分一样支持 EOS,则端到端支持 EOS。

SQL --CDC--> topic A --> App 1 --> topic B --> App 2 --> topic C

如果您在 CDC 步骤中使用 Kafka Connect,那么您必须检查您使用的连接器是否支持 EOS。

Everything I'm reading and every example I've found of the transactional api points to "streaming".

Kafka 生产者/消费者客户端的事务 API 为 EOS 处理提供原语。位于生产者/消费者客户端之上的 Kafka Streams 使用此功能来实现 EOS,开发人员只需几行代码即可轻松使用它(例如在应用程序需要时自动处理状态管理)进行有状态操作,如聚合或连接)。也许生产者/消费者 <-> Kafka Streams 之间的关系是您阅读文档后的困惑?

当然,您也可以在开发应用程序时使用底层的 Kafka 生产者和消费者客户端(使用事务性 API)“构建自己的”,但这需要更多工作。

I'm struggling to wrap my head around how we can use exactly-once with our Kafka topic, or if Kafka's exactly-once is even built for non-"streaming" use cases. Will we have to build our own deduplication and fault tolerance?

不确定“非流”用例是什么意思。如果你的意思是,“如果我们不想使用 Kafka Streams 或 KSQL(或其他可以从 Kafka 读取数据来处理数据的现有工具),我们需要做什么才能在我们的应用程序中实现 EOS?”,那么答案是“是的,在这种情况下,你必须直接使用 Kafka 生产者/客户,并确保你对它们所做的任何事情都正确地实现了 EOS 处理。” (并且因为后者比较困难,所以这个 EOS 功能被添加到 Kafka Streams 中。)

希望对您有所帮助。

关于java - 'exactly once' 是否仅适用于流(主题 1 -> 应用程序 -> 主题 2)?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/56065085/

24 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com