Azure HDInsight 5.1 提供最新的开源组件，并在性能、连接和安全性方面有了很大的增强。 本文档介绍如何将 HDInsight 4.0 (Kafka 2.1) 上的 Apache Kafka 工作负荷迁移到 HDInsight 5.1 (Kafka 3.2)。
Apache Kafka 版本
Apache Kafka 3.2.0
如果迁移到 Kafka 3.2.0 (HDI 5.1)，则可以利用以下新功能：
- 在 MM 2.0 中支持跨群集的自动使用者偏移同步，以便更轻松地跨群集迁移使用者或对其进行故障转移 KIP-545。
- 提示分区领导者恢复分区：这是一项新功能，允许控制器与新选择的主题分区领导者通信，无论它是否需要恢复其状态 KIP-704。
- 默认情况下，支持 TLS 1.2 以实现安全通信。
- Zookeeper 依赖项已被去除：生产者和使用者不再需要 zookeeper 参数。 通过 CLI 命令使用
--bootstrap-server选项而不是--zookeeperKIP-500。 - 用于创建接受器的可配置积压工作 (backlog) 大小：这是一种新配置，用于在中转站上设置 TCP 接受器套接字的 SYN 积压工作的大小 KIP-764。
- DescribeLogDirsResponse 的顶级错误代码字段：一种新的错误代码，使 DescribeLogDirs API 与其他 API 保持一致，并允许返回除 CLUSTER_AUTHORIZATION_FAILED 以外的其他错误 KIP-784。
有关完整的更新列表，请参阅 Apache Kafka 3.2.0 发行说明。
Kafka 客户端兼容性
新的 Kafka 中介支持旧版客户端。 KIP-35 - 检索协议版本介绍了一种动态确定 Kafka 中介功能的机制，KIP-97：改进了 Kafka 客户端 RPC 兼容性策略介绍了 Java 客户端的新兼容性策略和保证。 以前，Kafka 客户端必须与相同或更高版本的中介交互。 现在，更高版本的 Java 客户端以及其他支持 KIP-35 的客户端（例如 librdkafka）可以回退到较旧的请求类型，或者在功能不可用时引发相应的错误。
备注
建议使用与群集版本相同的 kafka 客户端版本。 有关详细信息，请参阅兼容性矩阵。
一般迁移过程
以下迁移指导假设在单个虚拟网络中的 HDInsight 4.0 上部署了 Apache Kafka 2.1.1 群集。 现有中介包含一些主题，并正在由生成者和使用者使用。 升级现有群集上的 Kafka 版本不受支持。 创建带有 HDI 5.1 的群集后，迁移 Kafka 客户端以使用新群集。
若要完成迁移，请执行以下步骤：
部署新的 HDInsight 5.1 群集和客户端以用于测试。 部署新的 HDInsight 5.1 Kafka 群集。 如果可以选择多个 Kafka 群集版本，建议选择最新版本。 部署后，根据需要设置一些参数，并创建与现有环境相同名称的主题。 此外，根据需要设置 TLS 和自带密钥 (BYOK) 加密。 然后，检查此设置是否可在新群集上正常工作。
切换生成者应用程序的群集，并等待所有队列数据已由当前使用者使用。 新的 HDInsight 5.1 Kafka 群集准备就绪后，将现有生产者目标切换到新群集。 在现有使用者应用已使用现有群集中的所有数据之前，请将此目标保持原样。
切换使用者应用程序上的群集。 确认现有使用者应用程序已用完现有群集中的所有数据后，将连接切换到新群集。
根据需要删除旧群集并测试应用程序。 完成切换并正常运行后，根据需要删除旧的 HDInsight 4.0 Kafka 群集，以及在测试中使用的生产者和使用者。
