Apache Kafka 3.0.0持续更新共识机制KRaft，并着手清理旧支持与设置

Apache Kafka 3.0.0正式发布，在众多更新中，这个版本最重要的两个重点，是API变更以及对KRaft的改进，而KRaft是Apache Kafka新的内置共识机制，将会取代分布式系统协调服务Apache ZooKeeper。

从Kafka 2.X版本开始，官方就开始启动移除Apache ZooKeeper的计划，ZooKeeper在Kafka中扮演协调代理的角色，当代理服务器启动时，需要向ZooKeeper注册，并由ZooKeeper管理代理的状态，也协助代理之间沟通与信息同步，因此在过去，Kafka需依赖ZooKeeper才能运行。

但是ZooKeeper是独立运行的系统，因此用户在使用Kafka的同时，还必须执行一套ZooKeeper系统，产生的问题除了资源浪费外，由于Zookeeper作为外部元资料存储服务，随着Kafka扩展Zookeeper所存储的元资料越多，加载的时间也越长，进而限制了Kafka集群扩展。

因此官方在近期的次要版本，重点都摆在Kafka Raft元资料模式（KRaft）这个Kafka内置的共识机制，以此作为Zookeeper的替代方案。不同于Zookeeper，KRaft是内置在Kafka中的控制器，能在Kafka集群内部执行，或是在特殊使用场景，移至专门的机器上执行也没问题。

Kafka 3的更新重点之一，也还是放在KRaft改进上，目前KRaft进入预览阶段，尚未完全取代Zookeeper，不过在部分系统运行上，已经逐渐不需要Zookeeper。

在3.0中，KRaft新加入的功能KRaft快照，让KRaft控制器和KRaft代理，来为名为__cluster_metadata的主题分区，产生、复制和加载快照，官方解释，Kafka集群使用该主题，来存储和复制有关集群的元资料信息，诸如代理配置和主题分区分配等，当这些状态随着时间增加变得复杂，Kafka快照能以有效率的方式，存储、加载和复制信息。

为了要让Kafka，能顺利地从Zookeeper切换到KRaft，开发团队重新设计了该工具的元资料记录类型，并让KRaft控制器开始在Zookeeper和KRaft模式下，负责产生Producer ID。而在Kafka Connect上，强化了任务重启功能，且改进Kafka Streams基于时间戳的同步功能，并赋给MirrorMaker2更灵活的配置选项。

除此之外，官方也开始一些清理工作，像是Kafka不再支持消息格式v0与v1，从2017年开始，消息格式v2就一直是默认格式，因此他们决定在Kafka 3中弃用旧版本，官方提到，旧格式已经很少被使用，在Kafka 3中，当用户选择使用旧版本消息格式，将会收到警告，预计Kafka４就会删除。

另外，官方也宣布在Kafka 3弃用Java 8的支持，包括所有Kafka中的Java 8组件，官方提到，Kafka 4将计划移除Java 8的支持，而现在给用户缓冲的时间进行更改。同时，Kafka 3也弃用Scala 2.12，对该语言的支持同样会在下一个主要版本移除。