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，对该语言的支援同样会在下一个主要版本移除。