我正在努力理解StatefulStream processor。
正如我所理解的，在这种类型的流处理器中，它使用State Store来维护某种状态。
我了解到，实现State Store的方法之一是使用RocksDB。假设以下topology(并且只有一个处理器是stateful(
A->B->C；处理器B为有状态，本地状态存储且启用了changelog。我正在使用低水平的API。
假设sp监听一个kafka主题，比如说topic-1有10个分区。
我观察到，当应用程序启动时(不同物理机器中的2个实例，num.stream.threads=5(，然后对于state store，它会创建目录结构有如下内容：
0_0、0_1、0_2…_0_9(每台机器有五个分区，因此总共有10个分区(。
我浏览了一些在线材料，其中说我们应该创建一个StoreBuilder，并使用addStateStore()来附加它的拓扑结构，而不是的在处理器内创建状态存储
类似：
topology.addStateStore(storeBuilder,"processorName")
Ref also: org.apache.kafka.streams.state.Store
我不明白将storeBuilder附加到拓扑结构与在处理器内实际创建状态存储有什么区别。它们之间有什么区别？
第二部分：对于statestore，它创建了如下目录：0_0、0_1等。谁以及如何创建它？kafka主题(sp正在侦听(和为State Store创建的目录数量之间是否存在某种1:1的映射？
我不明白将storeBuilder附加到拓扑与在处理器内实际创建状态存储有什么区别。它们之间有什么区别？
为了让Kafka Streams为您管理存储(容错、迁移(，Kafka Stream需要了解存储。因此，您给Kafka Streams一个StoreBuilder，Kafka Stream为您创建并管理存储。
如果你只是在处理器中创建一个存储，Kafka Streams就不会知道这个存储，而且这个存储也不会容错。
对于statestore，它会创建如下目录：0_0、0_1等。它是由谁创建的以及如何创建的？kafka主题(sp正在侦听(和为State Store创建的目录数量之间是否存在某种1:1的映射？
是的，有一个映射。存储是基于输入主题分区的数量共享的。每个分区还有一个"任务"，任务目录名为y_z，y是子拓扑编号，z是分区编号。对于简单拓扑，您只有一个子拓扑，所有目录都有相同的0_前缀。
因此，您的逻辑存储有10个物理碎片。当相应的输入主题分区被分配给不同的实例时，这种分片允许Kafka Streams对状态进行分片。总的来说，您最多可以运行10个实例，每个实例将处理一个分区，并托管存储的一个碎片。