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

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

在latest Kafka-Summit 期间，这个问题在talk of Gwen Shapira and Matthias J. Sax 之后提出了关于 Kubernetes 部署的问题。响应是相同的：如果您的升级包含拓扑修改，这意味着无法进行滚动升级。

目前似乎没有关于此的KIP。