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 4就會刪除。

另外,官方也宣布在Kafka 3棄用Java 8的支援,包括所有Kafka中的Java 8元件,官方提到,Kafka  4將計畫移除Java 8的支援,而現在給用戶緩衝的時間進行更改。同時,Kafka 3也棄用Scala 2.12,對該語言的支援同樣會在下一個主要版本移除。


熱門新聞

Advertisement