假设一个运行有状态的 Kafka 流有一个包含 16 个分区的输入主题，实例（或任务）的数量也是 16。据我所知，Kafka 生产者的默认分区器创建和分发的哈希值与分区的数量一样多。分区。因此，同样处于同一任务中的状态存储（Rocksdb）很可能随着分区数量的增加而经历不同的哈希值分布。
例如，如果我们将分区数量从 16 个增加到 32 个，我认为之前分布在 16 个分区内的状态存储的密钥分布也会受到影响，因为现在它分布在 32 个分区内。
我期望在幕后发生某种重新平衡，但尽管我进行了大量搜索，我只能找到与容错相关的内容。
如果我的简单想法是正确的，我想知道如果我想增加分区数量是否需要从头开始重新创建流应用程序。谁能阐明分区增加如何影响状态存储中的密钥分配以及我是否真的需要重建我的应用程序？预先感谢您。
分区数量是扩展 Streams 应用程序的固定上限。因此，明智的做法是提前计划并从比实例数量更多的分区开始，以便以后有扩展的空间。拥有比实例多得多的分区会产生一些成本，但 Kafka Streams 可以很好地处理。
如果您已经有一个 Streams 部署，并且想要扩展到超出当前分区数量，那么您确实需要从头开始重新创建状态。一种选择是关闭 Streams 应用程序，擦除状态目录并重新分区所有输入、输出和内部主题（重新分区主题和更改日志主题）。然后启动应用程序。它将从更改日志主题恢复状态，从而也在本地状态中应用新的分区。或者，您可以完全重新创建 Streams 应用程序（内部 + 输出主题）并将下游消费者热交换到新的输出主题 - 但速度会更慢。
有一个已接受但尚未实施的 KIP 将（部分）改善这种情况：