Java 全局状态存储与卡夫卡中的普通状态存储有何不同？

全局状态存储与普通状态存储有何不同

全局状态存储是否具有在不同计算机上运行的所有实例中的数据副本？ 由于全局状态存储不使用任何更改日志主题进行还原，因此在重新启动时它的行为在我的场景中全局存储的源主题没有键

全局状态存储是否具有在不同计算机上运行的所有实例中的数据副本

对

由于全局状态存储不使用任何更改日志主题进行还原，因此在重新启动时它的行为在我的方案中全局存储的源主题没有键：

• GlobalKTable

  默认情况下禁用日志记录，这样它就不会将changelog推送到

  GlobalKTable

  的changelog主题（不过它仍然会创建changelog主题）。您必须从启用日志压缩（cleanup.policy=compact）的输入主题将数据重新填充到

  GlobalKTable

  ，您要在

  GlobalKTable

  中查找哪个消息的键。重新启动应用程序时，Kafka Stream只需将数据从输入主题重新填充到

  GlobalKTable

• 在我的场景中，全局存储的源主题没有键：您必须使用KeyValueMapper将源主题映射到我上面提到的新主题，并在输出主题上启用日志压缩

---

请编辑问题，将其限制为特定问题，并提供足够详细的信息，以确定适当的答案。避免同时问多个不同的问题。请参阅页面以获取澄清此问题的帮助。更改它现在看起来很简单，有足够的详细信息。您是否询问GlobalKTable和Streams状态存储（使用RocksDB）之间的区别？我想知道全局状态存储是如何工作的。它在内部创建任何更改日志主题，以便在机器重新启动时还原。因为在我的场景中，全局状态存储的源主题没有键[key is null]，所以当我重新启动机器时。全局状态存储直接从源主题加载数据在使用它之前，请阅读

confluent kafka

的标记说明。它与Kafka Streams无关全局状态存储不创建任何用于恢复的更改日志主题吗？或者，唯一的解决方案是将数据重新分区到另一个主题，该主题将是全局状态存储的源主题global state use input topic，而不是用于恢复的changelog主题，但他们确实创建了changelog主题，在阅读您的问题后，文档中没有明确的状态，我运行了一个简单的拓扑来检查它，真的很惊讶。您可以在这里详细阅读“唯一的解决方案是将数据重新分区到另一个主题，该主题将是全局状态存储的源主题”，并且该主题必须启用日志压缩客户端id可以有多个用户。为此创建了新问题