Kafka Streams 应用程序更新

Question

我已经构建了一个 Kafka Streams 应用程序。这是我的第一个，所以我正在从概念验证的思维方式转变为“我如何将其产品化？” 心态。

tl;dr 版本：我正在寻找 kafka 流部署建议和技巧，特别是与更新您的应用程序代码相关的。

我已经能够找到很多关于 Kafka 和 Streams API 如何工作的文档，但我找不到关于实际部署 Streams 应用程序的任何内容。

初始部署似乎相当简单 - 有用于配置 Kafka 集群的良好文档，然后您必须为您的应用程序创建主题，然后您就可以启动它并发布数据以供处理。

但是如果您想稍后升级您的应用程序怎么办？具体来说，如果更新包含对拓扑的更改。我的应用程序在窗口中进行了大量的数据丰富和聚合，因此将来可能需要调整处理。

我的理解是，改变处理顺序或在拓扑中插入额外的步骤会导致每个处理步骤的内部 ID 发生变化，这意味着最多会创建新的状态存储，而先前的状态将丢失，最坏的情况是处理步骤启动时从不正确的状态存储主题中读取。这意味着您要么必须重置应用程序，要么为新版本提供新的应用程序 ID。但是这样做有一些问题：

1. 如果您重置应用程序或提供新的 id，处理将从源和中间主题的开头开始。我真的不想将输出发布到输出主题两次。
2. 当前，当您停止应用程序进行升级时，“运行中”数据将丢失（因为该应用程序永远不会再次启动以恢复处理）。

我能想到的缓解这种情况的唯一方法是：

1. 停止将数据发布到源主题。让应用程序处理所有消息，然后将其关闭。
2. 截断所有源和中间主题。
3. 使用新的应用程序 ID 启动新版本的应用程序。
4. 启动出版商。

现在这“没问题”，因为我的应用程序是唯一一个从源主题读取的内容，并且除了提供给同一应用程序中的下一个处理器之外，当前不使用中间主题。但是，我可以看到这变得非常混乱。

有没有更好的方法来处理应用程序更新？或者我的步骤通常与大多数开发人员所做的一样吗？

Answer 1

我认为您对这里的问题有一个全面的了解，并且您的解决方案似乎是大多数人在这种情况下所做的。

在最近一次 Kafka 峰会上，Gwen Shapira 和 Matthias J. Sax 谈论Kubernetes 部署后提出了这个问题。响应是相同的：如果您的升级包含拓扑修改，则意味着无法完成滚动升级。

目前看来还没有关于此的KIP 。