通过正常的k-streams工作，kafka将每个应用程序的偏移量存储在其内部偏移主题上。在应用程序重新启动时，应用程序将根据auto.offset.reset策略重新处理主题。这确实解释了here。
我正在使用kafka-stream的GlobalKTable来复制应用程序上的数据。但是我对应用程序的重启感到有点困惑，因为在重启后（由于部署或崩溃）id（StreamsConfig.APPLICATION_ID_CONFIG）没有改变的应用程序上没有填充它。每当我使用新id启动stream应用程序的新实例时，都会填充GlobalKTable。
GlobalKTable没什么不同，只是启用了日志压缩功能的主题。创建StreamsBuilder#globalTable状态的javadoc：
streamsBuilder.globalTable("some-topic", Materialized.as("kglobaltable-store"))
请注意，
GlobalKTable始终应用“auto.offset.reset”策略 “最早”，无论StreamsConfig中的指定值如何。
因此我希望，无论应用程序ID ，我的流应用程序从头开始读取kglobaltable-store主题并在本地填充商店，如github issue。似乎javadoc引用的主题是some-topic而不是kglobaltable-store。
这是GlobalKTable的预期行为吗？此外，是否有支持GlobalKTables的主题的保留政策？
当我们在kglobaltable-store上设置保留政策时，此行为还会导致some-topic主题上的陈旧数据。一个例子如下：
在时间t0，让;
some-topic：（1，a） - ＆gt; （2，b） - ＆gt; （1，c）
kglobaltable-store：[（1，c），（2，b）]
一段时间后（2，b）受保留，我启动我的流应用程序（带有新的id），而我的GlobalKTable只存储记录（1，c）如果是这种情况。< / p>
编辑：我正在使用InMemoryKeyValueStore。
答案 0 :(得分：1)
因为您使用InMemoryKeyValueStore我认为您遇到了这个错误：https://issues.apache.org/jira/browse/KAFKA-6711
作为一种变通方法，您可以删除全局存储的本地检查点文件（cf GlobalKTable checkpoints） - 这将在重新启动时触发引导。或者您切换回默认的RocksDB商店。
顺便说一句：如果您直接将某个主题作为表或全局表读取，Kafka Streams不会为容错创建额外的更改日志主题，但为此目的使用原始输入主题（这会降低卡夫卡集群）。因此，那些输入主题应该启用日志压缩。