亲爱的Apache Kafka朋友，
我有一个用例，我正在寻找一个优雅的解决方案:
数据以相对较高的速率在Kafka-Topic中发布。有两个相互竞争的需求
- 所有记录应保存7天(由min.compaction.lag配置)
- 应用程序应该读取"最后状态";
LogCompaction是按"最后状态"的顺序启用的。在主题中可用。现在问题来了。如果应用程序希望从主题初始化自己，它必须读取大量记录以获得所有键的最后状态(必须处理整个主题内容)。但是对于记录的数量，这在性能上是不可能的。
<<p>想法/strong>流处理将主题的数据流到相应的ShortTerm主题中，该主题具有更短的min. compaction_lag时间(1小时)。应用程序从这个主题初始化自己。
流处理是一个潜在的错误来源。如果临时失败，应用程序将不再接收最新状态。
我的问题
是否有其他可能的解决方案来满足这两个要求?我是否错过了一个有助于处理这些相互竞争的需求的Kafa概念?
欢迎任何贡献。谢谢大家。
如果你不能严格保证每个键的更新频率，你就不能按照你的建议做任何事情。
为了避免下游应用程序没有获得新更新的风险(因为数据复制作业停滞)，我建议只从短期主题引导应用程序，然后让它从原始主题消费。为了不错过任何更新，您可以按以下方式同步切换:
- 在应用程序启动时，从原始主题获取复制作业的已提交偏移量。
- 获取短期主题当前的结束偏移量(因为复制作业将继续写数据，只需要一个固定的停止点)。
- 消耗从开始到捕获的结束偏移量的短期主题。
- 使用捕获的已提交偏移量(从步骤1)作为起点，从原始主题恢复消费。
这样，您可能会读取一些消息两次，但不会丢失任何更新。
对我来说，你提到的两个需求和对新消费者的需求并不是相互竞争的。事实上，我看不出你为什么要在你的主题中保留一个过时的关键信息7天，因为
新- 消费者只对某个键的最新消息感兴趣。
- 现有消费者将在1小时内处理该消息(根据您的评论)。
所以我的理解是你的要求"所有记录保存7天"。可以用"每个消费者都应该有足够的时间来消费信息"来代替。每个密钥的最新信息应保存7天"
如果我说错了，请纠正我，并解释一下哪些消费者实际上需要"7天的所有记录"。
如果是这样的话，你可以这样做:
- 启用日志压缩和基于时间的保留到7天
- 将压缩频率微调到非常渴望，这意味着为一个键保留尽可能少的过时消息。
- 设置min.compact .lag为1小时，以便所有消费者都有机会跟上。
这样，新的消费者将(几乎)只读取每个键的最新消息。如果这还不够性能，您可以尝试增加您的消费者组的分区和消费者线程。