首页 > 解决方案 > Apache Kafka Streams:状态存储和主题分区分配

问题描述

我想了解一些有关如何将状态存储和主题分区分配给流处理应用程序及其任务的详细信息。

假设我有一个 4 分区主题 (tA)。我还有 4 个实例 (i0,i1,i2,i3) 相同的 application.id (myApp) 在 4 台不同的机器上运行并从 tA 流式传输记录。流引擎将为每个应用程序实例分配 1 个分区。为了争论,假设分区分配是:p0->i0、p1->i1、p2->i2 和 p3->i3 并且还假设我的流应用程序实例都创建了它们的状态存储 SS0、SS1、SS2、SS3 . 所以基本上,SS0 将保存对应于 p0、SS1->p1 等的记录(键)。

现在,如果 i0 和 i1 出现故障,并且如果 i2 和 i3 分别重新分配额外的分区 p0 和 p1。具有 p0 和 p1 键的相应状态存储也会被这些分区重新分配吗?

简而言之,我的问题是:分区和状态存储是否相互关联,以便在重新分配期间它们一起移动?即我们永远不会遇到获得 p0 的任务获得 ss1 的情况?

标签: apache-kafka-streams

解决方案


一个任务从一个特定的分区(或一组不同主题的分区)读取,一个任务还维护一个特定的状态存储。任务是在重新平衡分配期间移动的组件。

在您的示例中,Kafka Streams 应用程序将有 4 个任务,t0..t3。任务 t0 将从分区 p0 读取,从 p1 读取 t1,等等。每个任务将维护自己的状态存储。这意味着,任务 t0 将维护状态存储 SS0,t1 将维护 SS1,依此类推。

让我们假设实例 i0 执行任务 t0,i1 执行 t1 等。当实例 i0 和 i1 关闭时,任务 i0 和 i1 被重新分配给实例 i2 和 i3。现在,i2 将执行 t0 和 t2,并且 i3 将执行 t1 和 t3。由于状态存储是任务的一部分,因此它们将与它们一起迁移。如果具有状态的任务迁移到的实例没有保存状态的最新数据,则将在该实例上从 Kafka 代理的状态更改日志中恢复状态存储。请注意,一个任务还可以维护多个状态存储,例如当任务包含多个有状态操作时。

由于任务绑定到其输入分区及其状态存储,因此您永远不会遇到任务从不同分区读取或在迁移到不同实例后维护不同状态存储的情况。

您可以在以下链接下找到有关任务和状态存储的更多详细信息:


推荐阅读