分散式發布與訂閱系統Apache Kafka社群,發布了2.7.0這個遲來的版本,該版本的幾個重點更新,包括持續將Apache Kafka中的ZooKeeper替換掉,加入了新的內部代理API,並且增加新的Core Raft共識演算法的實作,現在Apache Kafka中具有單獨包含核心共識協定的Core Raft模組。另外,分層儲存的工作也持續進行中,以提供無限擴展和更快達到重新平衡的能力。

Zookeeper原本是在Apache Kafka中,扮演協調代理的角色,所有代理伺服器啟動時,都會連接到Zookeeper進行註冊,當代理狀態發生變化時,Zookeeper便會儲存這些資料,Kafka的代理會透過Zookeeper與其他代理溝通進行同步,也就是說Kafka沒有Zookeeper,也就無法順利運作。

不過,Zookeeper並非Kafka的一部分,因此運作每一個Kafka叢集,都必須部署兩套系統,這產生了許多問題,包括造成多餘資源的耗費,包括更多網路、監控功能以及安全性等資源配置,而Kafka叢集規模增加,也就代表Zookeeper必須要跟著擴展,必須使用更多的快取,且Zookeeper作為外部的元資料儲存服務,當元資料越來越多,使得控制器載入時間越來越長,限制了Kafka叢集的規模擴展。

因此在2019年的時候,Apache Kafka社群就開始移除Zookeeper的手術工作,要由Kafka本身提供元資料管理功能,而Apache Kafka 2.7.0總共有7個更新,與移除Zookeeper工作有關,包括了KIP-497新增內部代理API,來替換原本的內部同步副本(In-Sync Replica,ISR)。

目前Kafka分區負責程式(Partition Leader)和ISR資訊,皆儲存在Zookeeper中,控制器與分區負責程式都可以更新此狀態,但由於任一方都可以更新狀態,也就存在共享資訊的機制,而這會使ISR的更新出現延遲,也就代表元資料請求可能會收到舊資訊。

Apache Kafka 2.7.0加入了一個新的AlterIsr API,賦予控制器獨占能力,更新分區負責程式和ISR的狀態,新API的好處是讓元資料請求,總能獲得最新的狀態。官方提到,要刪除ZooKeeper,添加此API是重要的一步。

另外,當Kafka Streams應用程式的來源主題被刪除時,Kafka Streams現在可以正確發出異常訊息。目前,當用戶刪除正在執行的Kafka Streams來源主題,則嵌入的消費客戶端會被正常關閉,這會觸發重新平衡,直到Kafka Streams應用程式所有StreamThreads正常退出,應用程式完全關閉,而這過程沒有機會回應錯誤。在Apache Kafka 2.7.0,當用戶從正在運作的串流應用程式,刪除來源主題,該應用程式將丟出MissingSourceTopicException,讓用戶可以做出反應。

官方提到,因為Kafka叢集的規模日益增加,用戶需要在Kafka中儲存更多的資料,因此他們開始引入分層儲存的概念。Kafka的儲存現在分為本地端與遠端兩層,用戶可以將資料在本地暫存之後,丟到遠端進行較長期的儲存,如此,本地端儲存層留存資料的時間,將會從數天降到數小時,使用HDFS或S3等儲存系統的遠端層,就可以將資料留存數天甚至數月的時間。

熱門新聞


Advertisement