Kafka Processor API:Source 和 StateStore 的不同键?

rap*_*206 6 apache-kafka apache-kafka-streams

我们目前正在实施一个流程(使用 Kafka Processor API),我们需要将来自主题的 2 个相关事件(消息)的信息组合起来,然后转发这些组合信息。事件源自 IoT 设备,并且由于我们希望将它们保持有序,因此源主题使用设备标识符作为键。这些事件还包含一个相关 ID:

钥匙

{ deviceId: "..." }
Run Code Online (Sandbox Code Playgroud)

信息

{ deviceId: "...", correlationId: "...", data: ...}
Run Code Online (Sandbox Code Playgroud)

我们的第一种方法是创建一个具有连接状态存储的处理器,该状态存储使用相关 ID 作为键存储每条传入消息。这使我们能够在存储中查询传入消息的相关 ID,如果存储中已经存在具有相同 ID 的消息,我们可以组合这些信息,转发新事件并从存储中删除条目。因此,对于每个关联 ID,都会发生以下情况:在某个时间点,使用并存储具有该 ID 的第一条消息,而在其他时间点,具有该 ID 的第二条消息导致存储条目被删除。

状态键

{ correlationId: "..." }
Run Code Online (Sandbox Code Playgroud)

状态值

{ event: { deviceId: "...", correlationId: "...", data: ... }}
Run Code Online (Sandbox Code Playgroud)

但是现在我们想知道 Kafka Streams 如何处理不同的密钥。我们正在使用微服务方法,并且该服务将运行多个实例。该商店由内部主题自动支持。考虑重新缩放服务实例,重新平衡源主题和状态主题的分区。是否有可能将特定关联 ID 的分区分配给其他服务而不是相应设备 ID 的分区?我们是否会遇到这样一种情况,即具有相同关联 ID 的第二个事件将被服务实例使用,而该服务实例无权访问已存储的第一个事件?

提前致谢!

Mic*_*oll 7

如果我正确理解您的设置,那么是的,该方法是正确的,并且(重新)缩放将起作用。

TL;DR:如果一个流任务从机器 A 移动到机器 B,那么它的所有状态也将被移动,无论该状态如何键控(在您的情况下它恰好被键控correlationId)。

更详细地:

  • Kafka Streams 将处理工作分配给流任务。这是通过基于输入分区中的消息键(在您的情况下: keyed by deviceId)以确定性方式将输入分区映射到流任务来实现的。这确保了即使流任务在机器/虚拟机/容器之间移动,他们也将始终看到“他们的”输入分区=他们的输入数据。
  • 流任务本质上由实际处理逻辑(在您的情况下:处理器 API 代码)和任何关联的状态(在您的情况下:您有一个由 键控的状态存储correlationId)组成。对您的问题而言,重要的是状态的键控方式无关紧要。输入分区的键控方式仅重要,因为这决定了哪些数据从输入主题流向特定的流任务(请参阅上一个要点)。当一个流任务在机器/VM/容器之间移动时,它的所有状态也将被移动,以便它始终有“自己的”可用状态。

该商店由内部主题自动支持。

正如您已经建议的那样,存储具有内部主题(用于容错和弹性扩展,因为该内部主题用于在其流任务从 A 移至 B 时重建状态存储)这一事实是一个实现细节. 作为使用 Kafka Streams API 的开发人员,状态存储恢复的处理会自动且透明地为您完成。

当一个流任务被移动,因此它的状态存储被移动时,Kafka Streams 知道它需要如何在流任务的新位置重建状态存储。你不必担心。

是否有可能将特定关联 ID 的分区分配给其他服务而不是相应设备 ID 的分区?

不(这很好)。流任务将始终知道如何重建其状态(1+ 状态存储),而不管该状态本身是如何进行键控的。

我们是否会遇到这样一种情况,即具有相同关联 ID 的第二个事件将被服务实例使用,而该服务实例无权访问已存储的第一个事件?

不(这很好)。