升级指南和 API 变更

可以从任何旧版本升级到 {{fullDotVersion}}：如果从 3.4 或更低版本升级，您将需要进行两次滚动退回，其中在第一个滚动退回阶段您设置配置（可能的值为 ），在第二个阶段您删除它。这是安全处理 3 次更改所必需的。首先是引入嵌入式消费者的新协作再平衡协议。第二个是外键连接序列化格式的更改。 请注意，如果您跳过或延迟第二次滚动反弹，您将继续使用旧的急切再平衡协议，但是一旦整个组处于 2.4+ 状态，您就可以通过删除配置值和反弹来随时安全地切换到合作协议。有关更多详细信息，请参阅 KIP-429。第三个是内部重新分区主题的序列化格式的更改。有关更多详细信息，请参阅 KIP-904：upgrade.from="older version""0.10.0" - "3.4"

• 为滚动退回准备应用程序实例，并确保将 config 设置为要从中升级的版本。upgrade.from
• 退回应用程序的每个实例一次
• 为第二轮滚动退回准备新部署的 {{fullDotVersion}} 应用程序实例;确保删除 config 的值upgrade.from
• 再次退回应用程序的每个实例以完成升级

作为替代方案，也可以进行离线升级。在离线模式下从 0.10.0.x 及以下的任何版本升级到 {{fullDotVersion}} 需要执行以下步骤：

• 停止所有旧的 （例如 0.10.0.x） 应用程序实例
• 更新您的代码，并将旧代码和 JAR 文件替换为新代码和新 JAR 文件
• 重新启动所有新的 （{{fullDotVersion}}） 应用程序实例

注意：自 2.4 版本以来，协作式再平衡协议一直是默认协议，但我们继续支持 Eager Rebalancing 协议为用户提供升级路径。此支持将在将来的发行版中取消。 因此，任何仍在使用 Eager 协议的用户都应该准备在 3.1 版中完成将他们的应用程序升级到 Cooperative 协议。 这仅影响仍在使用 2.4 以上版本的用户，以及已升级但尚未升级的用户 删除了他们在从 2.4 以下版本升级时设置的配置。 适合后一种情况的用户在升级到 3.1 之后时只需取消设置此配置， 而前一种情况下的用户如果尝试从 2.3 或更低版本升级到 3.1 以上的版本，则需要遵循略有不同的升级路径。 这些应用程序需要通过 Bridge 版本，首先升级到 2.4 - 3.1 之间的版本并设置配置， 然后删除该配置并升级到 3.1 以上的最终版本。有关更多详细信息，请参阅 KAFKA-8575。upgrade.fromupgrade.from

有关显示 Streams API 与 Kafka 代理版本兼容性的表，请参阅代理兼容性。

过去版本中的显著兼容性更改

从 3.5.x 或更高版本降级到 3.4.x 或更早版本需要特别注意： 从 3.5.0 版本开始，Kafka Streams 对重新分区主题使用新的序列化格式。 这意味着旧版本的 Kafka Streams 将无法识别新版本写入的字节。 因此，将 3.5.0 或更高版本的 Kafka Streams 降级到正在运行的旧版本更加困难。为 更多详情，请参考 KIP-904。 对于降级，请先将配置切换到要降级到的版本。 这将禁止在应用程序中写入新的序列化格式。在此状态下等待很重要 足够长的时间以确保应用程序已完成处理写入的任何 “in-fly” 消息 以新的序列化格式进入 repartition 主题。之后，您可以将应用程序降级为 3.5.x 之前的版本。"upgrade.from"

从 3.0.x 或更高版本降级到 2.8.x 或更早版本需要特别注意： 自 3.0.0 版本起，Kafka Streams 使用更新的 RocksDB 版本，其磁盘格式发生了变化。 这意味着旧版本的 RocksDB 将无法识别该新版本的 RocksDB 写入的字节。 �