Kafka 3.0 需要关注哪些?

Posted 果汁华

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了Kafka 3.0 需要关注哪些?相关的知识,希望对你有一定的参考价值。

        Apache Kafka 3.0 是一个大版本,其引入了各种新功能、API 发生重大变化以及对 KRaft 的改进—— Apache Kafka 的内置共识机制将取代 Apache ZooKeeper™。

        虽然 KRaft 还不推荐在生产中使用,但我们对 KRaft 元数据和 API 进行了许多改进。支持 Exactly-once 和分区重分配值得强调。我们推荐您查看 KRaft 的新功能并在开发环境中试用它。

        从 Apache Kafka 3.0 开始,Producer 默认启用最强的交付保证(acks=all,enable.idempotence=true)。这意味着默认情况下消息将有序并且持久性。

        此外,不要错过 Kafka Connect 任务重启增强、Kafka Streams 基于时间戳同步的改进以及 MirrorMaker2 更灵活的配置选项。

普通变化

KIP-750 (Part I): Deprecate support for Java 8 in Kafka 

Apache Kafka 项目的所有组件在 3.0 中都将 Java 8 标记为 deprecated。这给用户足够的时间在下一个主要版本(4.0)之前进行调整,那时候 4.0 将不再支持 Java 8。

KIP-751 (Part I): Deprecate support for Scala 2.12 in Kafka

Apache Kafka 项目的所有组件在 3.0 中都将 Scala 2.12 标记为 deprecated。这给用户足够的时间在下一个主要版本(4.0)之前进行调整,那时候 4.0 将不再支持 Scala 2.12。

Kafka Broker, Producer, Consumer 和 AdminClient 方面的改进

KIP-630: Kafka Raft Snapshot 

我们在 3.0 中引入的一个主要功能是 KRaft Controllers 和 KRaft Brokers,能够为元数据主题 __cluster_metadata 的分区生成、复制和加载快照。Kafka 集群使用这个主题来存储和复制有关集群的元数据信息,例如 Broker 配置、topic 分区分配、leadership 等。随着此状态的增长,Kafka Raft Snapshot 提供了一种有效的方式来存储、加载和复制(replicate)这些信息 .
 

KIP-746: Revise KRaft Metadata Records

Kafka Raft Controller 第一版的经验和持续开发表明,我们需要修改一些元数据记录类型(metadata record types),这些元数据记录类型在 Kafka 配置不使用 ZooKeeper 的时候需要使用。

KIP-730: Producer ID generation in KRaft mode 

在 KIP-730 中,Kafka Controller 现在完全接管生成 Kafka Producer ID 的功能。Controller 在 ZK 和 KRaft 模式下都是这么做的。这让我们离桥式发布( bridge release)更近了一步,这将允许用户从使用 ZK 的 Kafka 部署过渡到使用 KRaft 的新部署。
 

KIP-679: Producer will enable the strongest delivery guarantee by default 

从 3.0 开始,Kafka Producer 默认打开幂等性(enable.idempotence=true)以及所有副本的交付都需要确认(acks=all)。这使得默认情况下记录的交付更加可靠。

KIP-735: Increase default consumer session timeout 

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

KIP-709: Extend OffsetFetch requests to accept multiple group ids 

支持请求 Kafka 消费者组的当前偏移量的功能已经存在一段时间了。但是获取多个消费者组的偏移量需要对每个组进行单独的请求。在 KIP-709 中,fetch 和 AdminClient API 被扩展为支持在单个请求/响应中同时读取多个消费者组的偏移量。

KIP-699: Update FindCoordinator to resolve multiple Coordinators at a time

支持能够同时高效地应用于多个消费者组的操作,在很大程度上取决于客户有效地发现这些组的协调者的能力。这可以通过 KIP-699 实现,它增加了对通过一个请求发现多个组的协调器的支持。Kafka 客户端已经更新在与新的支持此请求的 Kafka broker 交互时使用此优化。

以上是关于Kafka 3.0 需要关注哪些?的主要内容,如果未能解决你的问题,请参考以下文章

大数据Kafka都有哪些优势能力呢?

面试官:聊一聊 kafka 线上会遇到哪些问题?

Kafka-分区分配策略

Kafka 3.0 发布

Kafka 3.0 源码笔记-Kafka 服务端的启动与请求处理源码分析

2022年技术人365篇写作计划-想持续成长需要关注哪些能力