全局状态存储与kafka中的普通状态存储有何不同？
全局状态存储与普通状态存储有何不同？
全局状态存储是否在不同机器上运行的所有实例中都有数据副本？由于全局状态存储不使用任何更改日志主题进行恢复，因此在重新启动时它的行为在我的场景中全局存储的源主题没有键。
共有1个答案
>
全局状态存储是否在不同机器上运行的所有实例中都有数据副本？
对
GlobalKTable默认情况下禁用日志记录，这样它就不会将changelog推送到GlobalKTable的changelog主题（不过它仍然会创建changelog主题）。您必须从启用日志压缩（cleanup.policy=compact）的输入主题将数据重新填充到GlobalKTable，您要在GlobalKTable中查找哪个消息的键。重新启动应用程序时，Kafka Stream只需将数据从输入主题重新填充到GlobalKTable- 在我的场景中，全局存储中的源主题没有键：您必须使用KeyValueMapper将源主题映射到我上面提到的新主题，并在输出主题上启用日志压缩
-
在kafka中的全局状态存储是否总是一个分区，或者我们可以为全局状态存储更改日志主题设置多个分区？ 我找不到任何关于这方面的明确文件。
-
我已经阅读了有状态流处理概述，如果理解正确的话，RocksDB被用作键值存储的默认实现的主要原因之一是这样一个事实，即与内存中的集合不同，它可以处理大于可用内存的数据，因为它可以刷新到磁盘。这两种类型的存储都可以在应用程序重新启动时幸存下来，因为数据是作为Kafka主题备份的。 但还有其他不同吗？例如，我注意到我的持久状态存储为每个主题分区创建了一些。log文件，但它们都是空的。 简而言之，我想知
-
我目前正在考虑将opengl状态存储为某种适当类型的全局thread_local变量。那个设计有多糟糕？有什么陷阱吗？
-
我正在开发使用Spring Cloud Stream构建的Kafka Streams应用程序。在这个应用程序中，我需要： 使用可在以后检索的连续消息流。 保留与某些条件匹配的邮件 ID 列表。 在单独的线程中，运行一个计划程序，该计划程序定期读出消息 ID，检索与这些 ID 匹配的相应消息，并对这些消息执行操作。 从列表中删除已处理的消息 ID，以便不重复工作。 我已考虑如下实施： < li >将
-
问题内容： 广泛的讨论问题。是否已经有任何库可以让我在Java中存储应用程序的执行状态？ 例如，我有一个处理文件的应用程序，现在该应用程序可能在某个时刻被迫关闭。我想存储所有已处理文件和未处理文件的信息，以及处理正在进行的阶段正在进行的流程。 是否已经有抽象此功能的库，或者我将不得不从头开始实现它？ 问题答案： 似乎您正在寻找的是可以使用Java Serialization API 执行的序列化。
-
对于删除记录，我执行如下操作 Kafka如何知道记录被删除，在恢复过程中，它将从源主题转储记录（考虑源主题有一条键为-1的记录） 在我的拓扑中 null null 在状态存储中更新相同内容 我只想知道，在恢复过程中，该记录将被删除，这意味着如果使用键进行get on store时，我将得到null。