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

Question

我正在尝试理解有状态流处理器。

据我所知，在这种类型的流处理器中，它使用状态存储来维护某种状态。

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

A-

假设sp只监听一个Kafka主题，比如带有10个分区的topic-1。

我观察到，当应用程序启动时（在不同的物理机器上有2个实例，并且num.stream.threads=5），然后对于状态存储，它会创建目录结构，其内容如下：

0_0，0_1，0_2......0_9（每台机器有5个分区）。

我正在浏览一些在线资料，其中说我们应该创建一个StoreBuilder，并使用addStateStore（）将其连接到拓扑结构，而不是在处理器中创建状态存储。

喜欢：

topology.addStateStore(storeBuilder,"processorName")

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

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

第二部分：为statestore创建目录，如：0\u 0、0\u 1等。谁以及如何创建它？其中Kafk: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映射？

是的，有一个地图。该存储区以输入主题分区的数量为基础进行共享。每个分区也有一个“任务”，任务目录是namey_z，其中y是子拓扑编号，z是分区编号。对于简单拓扑，只有一个子拓扑指向所有具有相同前缀的目录。

因此，逻辑存储有10个物理碎片。当相应的输入主题分区被分配给不同的实例时，这种分片允许Kafka流进入Mirregate状态。总的来说，您最多可以运行10个实例，每个实例将处理一个分区，并托管一个存储碎片。