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，對該語言的支援同樣會在下一個主要版本移除。