Kafka 处理器 API：Source 和 StateStore 的密钥不同？
Kafka Processor API: Different key for Source and StateStore?
我们目前正在实施一个流程（使用 Kafka 处理器 API），我们需要将来自 2 个相关事件（消息）的信息组合到一个主题上，然后转发这些组合信息。这些事件源自 IoT 设备，并且由于我们想让它们保持有序，因此源主题使用设备标识符作为键。这些事件还包含相关 ID：
密钥
{ deviceId: "..." }
留言
{ deviceId: "...", correlationId: "...", data: ...}
我们的第一种方法是创建一个具有连接状态存储的处理器，它使用关联 ID 作为键来存储每条传入消息。这使我们能够查询存储以获取传入消息的相关 ID，如果存储中已经存在具有相同 ID 的消息，我们可以合并信息、转发新事件并从存储中删除条目。因此，对于每个相关 ID，都会发生以下情况：在某个时间点，使用并存储具有该 ID 的第一条消息，而在其他时间点，具有该 ID 的第二条消息导致存储条目被删除。
状态键
{ correlationId: "..." }
状态值
{ event: { deviceId: "...", correlationId: "...", data: ... }}
但现在我们想知道 Kafka Streams 如何处理不同的密钥。我们正在使用微服务方法，该服务将有多个实例 运行。该商店自动由内部主题支持。考虑重新扩展服务实例，s.t。源主题和状态主题的分区被重新平衡。是否有可能将特定相关 ID 的分区分配给另一项服务而不是相应设备 ID 的分区？我们是否会遇到这样一种情况：具有相同相关 ID 的第二个事件将被服务实例使用，而该服务实例无权访问已存储的第一个事件？
提前致谢！
如果我正确理解您的设置，那么是的，该方法是正确的，（重新）缩放将起作用。
TL;DR：如果一个流任务从机器 A 移动到机器 B，那么它的所有状态也将被移动，无论该状态是如何输入的（在你的情况下它恰好由 correlationId).
更详细：
- Kafka Streams 将处理工作分配给 stream tasks。这是通过基于输入分区中的消息键（在您的情况下：由
deviceId 键控）以确定性方式将输入分区映射到流任务来实现的。这确保即使流任务在 machines/VMs/containers 之间移动，它们也将始终看到 "their" 输入分区 = 它们的输入数据。
- 流任务基本上由实际处理逻辑（在您的情况下：处理器API代码）和任何关联的状态组成（在您的情况下：您有一个由
correlationId 键控的状态存储）。对于您的问题来说重要的是，状态的键控方式并不重要。唯一重要的是输入分区的键控方式，因为这决定了哪些数据从输入主题流向特定的流任务（参见前面的要点）。当一个流任务在 machines/VM/containers 中移动时，它的所有状态也将被移动，以便它始终有 "its own" 个可用状态。
The store is automatically backed by an internal topic.
正如您已经提到的，存储有一个内部主题（用于容错和弹性缩放，因为当流任务从 A 移动到 B 时，该内部主题用于重建状态存储) 是一个实现细节。作为使用 Kafka Streams 的开发人员 API，状态存储恢复的处理是自动透明地为您完成的。
当流任务及其状态存储被移动时，Kafka Streams 知道它需要如何在流任务的新位置重建状态存储。你不用担心这个。
Is is possible that the partition for a specific correlation ID is assigned to another service than the partition for the corresponding device ID?
没有（这很好）。流任务将始终知道如何重建其状态（1+ 状态存储），无论该状态本身是如何键控的。
Could we end up in a situation were the second event with the same correlation ID would be consumed by a service instance, that does not have access to the already stored first event?
没有（这很好）。
我们目前正在实施一个流程（使用 Kafka 处理器 API），我们需要将来自 2 个相关事件（消息）的信息组合到一个主题上，然后转发这些组合信息。这些事件源自 IoT 设备，并且由于我们想让它们保持有序，因此源主题使用设备标识符作为键。这些事件还包含相关 ID：
密钥
{ deviceId: "..." }
留言
{ deviceId: "...", correlationId: "...", data: ...}
我们的第一种方法是创建一个具有连接状态存储的处理器，它使用关联 ID 作为键来存储每条传入消息。这使我们能够查询存储以获取传入消息的相关 ID，如果存储中已经存在具有相同 ID 的消息，我们可以合并信息、转发新事件并从存储中删除条目。因此，对于每个相关 ID，都会发生以下情况：在某个时间点，使用并存储具有该 ID 的第一条消息，而在其他时间点，具有该 ID 的第二条消息导致存储条目被删除。
状态键
{ correlationId: "..." }
状态值
{ event: { deviceId: "...", correlationId: "...", data: ... }}
但现在我们想知道 Kafka Streams 如何处理不同的密钥。我们正在使用微服务方法，该服务将有多个实例 运行。该商店自动由内部主题支持。考虑重新扩展服务实例，s.t。源主题和状态主题的分区被重新平衡。是否有可能将特定相关 ID 的分区分配给另一项服务而不是相应设备 ID 的分区？我们是否会遇到这样一种情况：具有相同相关 ID 的第二个事件将被服务实例使用，而该服务实例无权访问已存储的第一个事件？
提前致谢！
如果我正确理解您的设置，那么是的，该方法是正确的，（重新）缩放将起作用。
TL;DR：如果一个流任务从机器 A 移动到机器 B，那么它的所有状态也将被移动，无论该状态是如何输入的（在你的情况下它恰好由 correlationId).
更详细：
- Kafka Streams 将处理工作分配给 stream tasks。这是通过基于输入分区中的消息键（在您的情况下：由
deviceId键控）以确定性方式将输入分区映射到流任务来实现的。这确保即使流任务在 machines/VMs/containers 之间移动，它们也将始终看到 "their" 输入分区 = 它们的输入数据。 - 流任务基本上由实际处理逻辑（在您的情况下：处理器API代码）和任何关联的状态组成（在您的情况下：您有一个由
correlationId键控的状态存储）。对于您的问题来说重要的是，状态的键控方式并不重要。唯一重要的是输入分区的键控方式，因为这决定了哪些数据从输入主题流向特定的流任务（参见前面的要点）。当一个流任务在 machines/VM/containers 中移动时，它的所有状态也将被移动，以便它始终有 "its own" 个可用状态。
The store is automatically backed by an internal topic.
正如您已经提到的，存储有一个内部主题（用于容错和弹性缩放，因为当流任务从 A 移动到 B 时，该内部主题用于重建状态存储) 是一个实现细节。作为使用 Kafka Streams 的开发人员 API，状态存储恢复的处理是自动透明地为您完成的。
当流任务及其状态存储被移动时，Kafka Streams 知道它需要如何在流任务的新位置重建状态存储。你不用担心这个。
Is is possible that the partition for a specific correlation ID is assigned to another service than the partition for the corresponding device ID?
没有（这很好）。流任务将始终知道如何重建其状态（1+ 状态存储），无论该状态本身是如何键控的。
Could we end up in a situation were the second event with the same correlation ID would be consumed by a service instance, that does not have access to the already stored first event?
没有（这很好）。