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 交互时使用此优化。