详解Kafka 3.0 稳定版新特性

朱雀 2024-04-01 15:43 41阅读 0赞

## **第一部分: 基础升级** ##

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

![10d8b8f1ec2540a0bd5a61b9180f31c4.png][]

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** **的支持** ####

![f6365916151244499ac736037238c59b.png][]

### **第二部分: kafka Raft 快照** ###

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

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

![8bd3abd9ff554c6c8bce25f0402fa78d.png][]

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

![22680c8e41b749c3bf2cdd49f03f8e27.png][]

![50316b7e342e470fbeaeb065edfff620.png][]

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

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

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

![0a55a9f75a594ff1ba63d84dd02a6fa5.png][]

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

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

![33aed9a800f0469b97de55e26b425cf3.png][]

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

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

![4db578e340d848bb94bd473ab2e0e161.png][]

### **第六部分: 删除对消息格式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 主题传送到二级存储和查询系统或批处理系统进行离线分析。

![5da06decd9164707805848a0d921508d.png][]

#### **第一部分: 连接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, 这样所有的客户端可以响应回馈其偏移量信息, 以方便对所有任务的进行进度监控工作

![13d600d518854d15bb9b3bf9266a4ea0.png][]

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

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

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

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

![5c22d86dda8e4ec4b61e8045bfc61ea1.png][]

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

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

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

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

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

[10d8b8f1ec2540a0bd5a61b9180f31c4.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/21775cdb880b4fb2a75a3aec615bf6d8.png
[f6365916151244499ac736037238c59b.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/7931a9dcb0e84ca1ae974ca9bfb1df9a.png
[8bd3abd9ff554c6c8bce25f0402fa78d.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/3f98e3a39de14389a81334fbf6e0cab7.png
[22680c8e41b749c3bf2cdd49f03f8e27.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/5122e20e75464e61adbd0948ce103abe.png
[50316b7e342e470fbeaeb065edfff620.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/d3bd40a13a6d4d8a8d079effddc52d4e.png
[0a55a9f75a594ff1ba63d84dd02a6fa5.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/e086942a36234da2872c1fdaef09a1f4.png
[33aed9a800f0469b97de55e26b425cf3.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/4d0451585939430f942fc67e2198510b.png
[4db578e340d848bb94bd473ab2e0e161.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/5d6be1a5dec545f0a1ae812bd98e9d34.png
[5da06decd9164707805848a0d921508d.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/599844805f104427a236f6839092b2c4.png
[13d600d518854d15bb9b3bf9266a4ea0.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/62ca95bc319c423fb67602fd19738c0e.png
[5c22d86dda8e4ec4b61e8045bfc61ea1.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/4e1434f1049b45df8fae1b265f527f4b.png