带有 statestore 的 Kafka 有状态流处理器：幕后

Question

我想了解StatefulStream processor。

据我了解，在这种类型的流处理器中，它使用State Store 维护某种状态。

我知道，实现State Store 的方法之一是使用RocksDB。假设以下topology（并且只有一个处理器是stateful）

A->B->C;处理器 B 具有 local 状态存储和 changelog 启用 状态。我正在使用低级 API。

假设 sp 侦听单个 kafka 主题，假设 topic-1 有 10 个分区。

我观察到，当应用程序启动时（不同物理机中的 2 个实例和 num.stream.threads = 5），然后为 state store 创建目录结构 有如下内容：

0_0 , 0_1, 0_2.... 0_9 （每台机器有 5 个所以总共 10 个分区）。

我浏览了一些在线材料，上面说我们应该创建一个StoreBuilder 并使用addStateStore() 附加拓扑而不是 创建一个状态存储在处理器中。

喜欢：

topology.addStateStore(storeBuilder,"processorName")

Ref also: org.apache.kafka.streams.state.Store

我不明白将 storeBuilder 附加到拓扑与实际在处理器中创建 statestore 有什么区别。它们之间有什么区别？

第二部分：对于 statestore，它创建目录，例如：0_0、0_1 等。它是由谁以及如何创建的？ kafka 主题（sp 正在监听的）与为State Store 创建的目录数量之间是否存在某种 1:1 映射？

Answer 1

我不明白将 storeBuilder 附加到拓扑与实际在处理器中创建 statestore 有什么区别。它们之间有什么区别？

为了让 Kafka Streams 为您管理存储（容错、迁移），Kafka Streams 需要了解存储。因此，您给 Kafka Streams 一个 StoreBuilder，然后 Kafka Streams 会为您创建和管理商店。

如果你只是在你的处理器中创建一个存储，Kafka Streams 不知道存储并且存储不会容错。

对于 statestore，它会创建如下目录：0_0、0_1 等。它是由谁以及如何创建的？ kafka 主题（sp 正在监听的）与为 State Store 创建的目录数量之间是否存在某种 1:1 映射？

是的，有一个映射。存储在输入主题分区的数量上是共享的。您还可以获得每个分区的“任务”，任务目录名称为 y_z，y 是子拓扑编号，z 是分区编号。对于您的简单拓扑，您看到的所有目录只有一个子拓扑，具有相同的 0_ 前缀。

因此，您的逻辑存储有 10 个物理分片。当相应的输入主题分区分配给不同的实例时，此分片允许 Kafka Streams 迁移状态。总体而言，您最多可以运行 10 个实例，每个实例将处理一个分区，并托管您存储的一个分片。