第一部分: 基础升级

1: 弃用 Kafka 中对 Java 8 的支持

Kafka 目前支持 Java 8、11 和 15（即将为 16）。换句话说，我们支持两个最新的 LTS 版本和最新的非 LTS 版本。由于我们必须在每个受支持的版本上编译和运行测试，因此从开发和测试的角度来看，这是一笔不小的成本。

Java 17 将于今年晚些时候发布，它将是一个 LTS 版本。为避免在 Java 18 发布后支持 4 个 Java 版本，我们希望放弃对 Java 8 的支持。但是，还有其他注意事项：

尽管 Java 8 于 2014 年 3 月（7 年前）发布，但它仍然是使用最广泛的 Java 版本。Java 11 于 2018 年 9 月（近 3 年前）发布。

在我们删除对给定 Java 版本的支持之前需要一个弃用期，并且删除应该发生在主要的 Kafka 版本中。

我们依赖的重要项目可能会先于我们取消对 Java 8 的支持，这可能会在涉及 CVE 所需的更新时带来挑战。一个例子是Jetty 10。

在所有应用程序中升级 Java 版本通常比在服务（例如代理、连接等）中升级 Java 版本更难。

我们预计 Apache Kafka 3.0 将在 2021 年 7 月/8 月左右发布，而 4.0 将在此后至少 16 个月发布。鉴于此和上述情况，我们建议弃用 Apache Kafka 3.0 中的 Java 8 支持并放弃 Apache Kafka 4.0 中的支持。用户将有足够的时间和警告从 Java 8 迁移。

继续在客户端模块中支持 Java 8。

 2: 弃用 Kafka 中对 scala 2.12 的支持

 第二部分: kafka Raft 快照

Kafka 2.8.0正式发布了KRaft的先行版，并且支持在KRaft模式下的部署和运行。KRaft模式下的Kafka可以完全脱离Zookeeper运行，使用自己的基于Raft算法实现的quorum来保证分布式Metadata的一致

        而这样我们只需要管理和配置一项服务即可, 让kafka集群更加具有可扩展性, 并且让其能够支持更多的topic和partition

         Kafka 3.0 发布,在kafka 的Raft模式下, 引入了一个主要的功能是快照: 能够为kraft控制器和brokers的元数据分区主题(__cluster_metadata)提供更加有效的存储, 加载和复制这些信息

 

 第三部分: KRaft 模式下的生产者 ID 生成

Kafka Controller在3.0完全接管了生成 Kafka 生产者 ID 的责任。 Controller在 ZK 和 KRaft 模式下都这样做。这让我们离开桥接版本更近了，这将允许用户从使用 ZK 的 Kafka 部署过渡到使用 KRaft 的新部署。

       PID 生成在前序的版本中实现使用的是利用 ZooKeeper 进行持久性和并发控制的块生成方案。每次代理需要分配一个新的 PID 块时，它将使用 ZooKeeper 的 setData API 来分配下一个块

 第四部分: Producer将默认启动最强的交付保障

    从 3.0 开始，Kafka Producer 默认开启幂等性和所有副本的交付确认。这使得默认情况下记录交付保证更强。

 第五部分: 增加默认消费者会话超时

Kafka Consumer 的配置属性的默认值session.timeout.ms从 10 秒增加到 45 秒。这将允许消费者在默认情况下更好地适应暂时的网络故障，并在消费者似乎只是暂时离开组时避免连续重新平衡。

第六部分: 删除对消息格式V0和V1的支持 

如果有从事过kafka从 0.11.x以下升级到0.11.x以上版本的程序员应该清楚, kafka为了能够保证在升级过程中不会出现停止, 可以完成滚动升级的计划, 提供了消息格式版本, 分别为V0,V1,V2(0.11.x以后),V3(3.x) 等.

    而目前大部分的kafka的程序员使用的都是V2的消息版本,也就是0.11.x以上的相关版本, 故在3.0中将对v0和v1的消息格式进行弃用, 不推荐使用其写入. 从而在kafka4.0中完全剔除

Kafka Connect 升级

什么是kafka Connect

    Kafka Connect 是一种用于在 Apache Kafka 和其他系统之间可扩展且可靠地流式传输数据的工具。它使快速定义将大量数据移入和移出 Kafka 的连接器变得简单。Kafka Connect 可以摄取整个数据库或从所有应用程序服务器收集指标到 Kafka 主题中，使数据可用于低延迟的流处理。导出作业可以将数据从 Kafka 主题传送到二级存储和查询系统或批处理系统进行离线分析。

 第一部分: 连接API以重新启动连接器和任务

当用户在 Apache Kafka Connect 上运行连接器时，框架会启动连接器Connector一个实例和一个或多个实例Task。这些实例中的任何一个都可能遇到错误。通常，如果ConnectororTask 实例抛出异常，Connect 框架会将该实例标记为失败，并通过 Connect REST API 将其公开为 FAILED。

        目前，用户必须使用 REST API 状态方法和/或 JMX 指标来监控每个命名连接器Connector 和Task 实例的运行状况（“状态”）  。如果这些实例中的任何一个失败，用户必须发出单独的 REST API 调用以手动重新启动每个Connector和Task实例。

        Connect REST API 应该允许用户Connector 使用单个 REST API 调用重新启动所有失败的和 Task 实例。

        在 3.0 中，使用户能够通过一次调用重新启动所有或仅失败的连接器Connector和Task实例。此功能是附加功能，restartREST API的先前行为保持不变

第二部分: 默认启动连接器客户端覆盖

        从Apache Kafka 2.3.0 开始，可以配置 Connect worker 以允许连接器配置覆盖连接器使用的 Kafka 客户端属性。这是一个广泛使用的功能，在3.0中，默认启用覆盖连接器客户端属性的功能（默认connector.client.config.override.policy设置为All）。

第三部分: 启动连接器日志上下文

另一个在 2.3.0 中引入但到目前为止尚未默认启用的功能是连接器日志上下文(将连接器上下文添加到 Connect 工作器的日志中)。这在 3.0 中发生了变化，连接器上下文默认添加log4j到 Connect 工作器的日志模式中。

Kafka Stream 升级

第一部分: 开放在流中关于偏移量API

        在使用kafka中, 我们如果想要跟踪客户端的消息的进度, 可以根据其返回的偏移量信息来判断, 但是此操作在kafka的stream中并没有提供, 因为stream的客户端中嵌入了多个kafka客户端(发送和消费)

         在kafka3.0中对stream客户端开放其偏移量相关的API, 这样所有的客户端可以响应回馈其偏移量信息, 以方便对所有任务的进行进度监控工作

 第二部分: 新增及更改相关的API

1) 将TaskMetadata 和 ThreadMetadata迁移到具体内部实现的接口

       在原有的版本中TaskMeataData和ThreadMeatadata都是具体的实现类, 但是在实际使用中都不需要用户进行实例化, 仅使用公开的元数据API, 所以在kafka3.0中都将进行分离, 形成公共接口,将具体的实现保留为内部类即可

2) 扩展了ReadOnlySessionStore和SessionStore接口中的一组新方法  

3) 在ProcessorContext类中增加两个新的方法 

 在kafka3.0 中processorContext增加两个新的方法: currentSystemTimeMs 和 CurrentStreamTimeMs.

这两个新的方法可以让用户分别查询缓存的系统时间和流时间, 起到统一API的作用

第三部分: 更改kafka Streams默认副本因子配置

Streams 配置属性的默认值replication.factor会从 1 更改为 -1。这将允许新的 Streams 应用程序使用在 Kafka Broker 中定义的默认复制因子，因此在它们转移到生产时不需要设置此配置值。请注意，新的默认值需要 Kafka Brokers 2.5 或更高版本。