Apache Kafka 2.7.0發布，加速移除分散式系統協調服務Zookeeper

分散式發布與訂閱系統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等儲存系統的遠端層，就可以將資料留存數天甚至數月的時間。