我想了解一些关于如何将状态存储和主题分区分配给流处理应用程序及其任务的详细信息。
假设我有一个4部分的主题(tA(。我还有同一应用程序.id(myApp(的4个实例(i0、i1、i2、i3(在4台不同的机器上运行，并从tA流式传输记录。流引擎将为每个应用程序实例分配一个分区。为了便于论证，假设分区分配为：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的情况？
任务从一个特定分区(或一组不同主题的分区(读取，任务还维护一个特定的状态存储。任务是在重新平衡的分配过程中移动的组件。
在您的示例中，Kafka Streams应用程序将有4个任务，t0..t3。任务t0将从分区p0读取，t1将从p1读取，等等。每个任务将维护其自己的状态存储。这意味着，任务t0将保持状态存储SS0，t1将保持SS1，依此类推
假设实例i0执行任务t0，i1执行t1等。当实例i0和i1宕机时，任务i0和i 1被重新分配给实例i2和i3。现在，i2将执行t0以及t2，并且i3将执行t1以及t3。由于状态存储是任务的一部分，因此它们将与状态存储一起迁移。如果具有状态的任务迁移到的实例没有保存该状态的最新数据，则将从Kafka代理上的状态更改日志中恢复该实例的状态存储。请注意，任务还可以维护多个状态存储，例如，当任务包含多个有状态操作时。
由于任务绑定到其输入分区和状态存储，因此在迁移到不同实例后，您永远不会遇到任务从不同分区读取或维护不同状态存储的情况。
您可以在以下链接下找到有关任务和状态存储的更多详细信息：
- https://www.confluent.io/blog/how-to-tune-rocksdb-kafka-streams-state-stores-performance/
- https://kafka.apache.org/28/documentation/streams/architecture