生产中 kafka-streams 拓扑的演变答案

【问题标题】：Evolution of kafka-streams topology in production生产中 kafka-streams 拓扑的演变
【发布时间】：2026-01-23 05:40:01
【问题描述】：

我有一个复杂的拓扑结构，包括 KStreams、KTables、joins、rekeying、filters、through、branching、zips 等，以及输出主题的实时客户端。

所有输入、中间和输出主题都是基于 avro 的主题。

如何处理拓扑的更改（添加新步骤、新的输入-中间-输出主题），知道 kafka-streams 维护内部状态和更改日志，符合以下业务要求：

答案是介于使用kafka-streams-application-reset 还是创建全新的消费者组（应用程序ID）之间？

【问题讨论】：

【解决方案1】：

目前，Kafka Streams 中没有检查点或保存点类型的概念。

如果您需要更新现有的应用程序，使用新的application.id或重置现有的application.id是安全的。

有些场景需要根据拓扑的变化定义一个新的application.id。

【讨论】：

感谢您的回答。如果我重置应用程序 ID，KStream-KTable 加入会发生什么？ kafka-streams 是否足够聪明，可以在加入 KStream 之前重新填充 KTable？
是的，通常在应用程序考虑运行和执行连接等转换之前，Ktable 上的内部存储会从底层主题中收取费用。
如果您重置应用程序 ID，它会删除所有底层变更日志主题。因此无法重新填充 ktable。它将是在下一次运行中创建的新 ktable，其中包含新的变更日志主题和状态存储..
这取决于时间戳。如果 KTable 记录的时间戳小于 KStream 记录，则 KTable 记录将首先放入 KTable（您需要 2.1 版本——在旧版本中，时间戳同步只是尽力而为）
创建另一个主题或以其他方式使用相同的密钥并执行压缩以删除旧记录是安全的