Apache Kafka 2.7.0 穩定版發布，有哪些值得關心的變化？

Apache Kafka 2.7.0 于2020年12月21日正式發布，這個版本是目前 Kafka 最新穩定版本，大家可以根據需要自行決定是否需要升級到次版本，關于各個版本升級到 Apache Kafka 2.7.0 請參見《Upgrading to 2.7.0 from any version 0.8.x through 2.6.x》，

在這個版本中，社區仍然在推進從 Kafka 移除對 ZooKeeper 的依賴，比如這個版本在 KIP-497 里面添加了可以修改 ISR 的 Broker 內部 API；在 KIP-500 里面增加了自元數管理（Self-Managed Metadata Quorum）的 Raft 核心實作，這個也是去掉 Zookeeper 的一部分作業，現在在 Kafka 的源代碼里面有一個名為 raft 的模塊專門用于實作共識協議（consensus protocol），在與控制器（Kafka 集群中負責管理磁區和副本狀態的 broker）的集成完成之前，有一個獨立的服務器可以用來測驗 Raft 實作的性能，

當然，為了取代 Zookeeper，還有更多的作業正在努力進行中，很多 KIP 正在積極開發中，以使得每個集群能夠支持更多的磁區、更簡單的操作和更嚴格的安全性，

分級存盤（Tiered Storage）作業也正在繼續進行中，這個可以參見 KIP-405，

如果想及時了解Spark、Hadoop或者HBase相關的文章，歡迎關注微信公眾號：iteblog_hadoop 如果需要下載 Apache Kafka 2.7.0，可以到 這里下載，由于時間和篇幅的關系，下面我們只介紹 Kafka 2.7.0 版本部分變化，更多內容請參見 Kafka 2.7.0 Release Notes，

Kafka broker, producer 和 consumer 的更新

KIP-654: 終止帶有任何未重繪資料的事務時拋出一個非致命例外

在 Kafka 2.7.0 之前，當 Java client producer 程式終止帶有任何未重繪（掛起）資料的事務時，將拋出一個致命例外，但是，終止一個有掛起資料的事務實際上被認為是一種正常的情況，拋出的例外應該是通知我們沒有發送記錄，而不是通知應用程式處于不可恢復狀態，所以，在 KIP-654 中引入了一個名為TransactionAbortedException 的例外，允許我們在需要時重試，

KIP-651: 私鑰和 SSL證書支持 PEM 格式

目前，Kafka 在使用 SSL 時只支持基于 JKS 或 PKCS12 檔案的密鑰和信任存盤，雖然 Privacy-Enhanced Mail （PEM）不再是電子郵件的標準，但它是存盤和分發加密密鑰和證書的標準格式，在 KIP-651 中為密鑰和信任存盤增加了對 PEM 檔案的支持，允許使用依賴于 PEM 格式的第三方提供商，

KIP-612: 能夠限制 broker 上的連接創建速率

創建連接會給 broker 增加 CPU 開銷，連接風暴（Connection storms）可能來自表面上表現良好的客戶機，并可能阻止 broker 執行其他有用的作業，這個版本添加了一種方法可以強制限制每個 broker 中每個監聽器創建連接的速率，2.7.0 版本包含了 KIP-612 的第一部分，每個 IP 的連接限制預計會在 2.8.0 版本中出現，

KIP-599: 支持對創建主題、創建磁區和洗掉主題的操作進行節流

創建主題、創建磁區和洗掉主題的 API 是直接影響 Kafka 控制器總體負載的操作，為了防止由于高并發主題和磁區創建或主題洗掉而導致集群不堪重負，KIP-599 中引入了一個新的配額來限制這些操作，

KIP-584: Versioning scheme for features

除了 broker-client 之間的兼容性，其他方面的兼容性比較差，比如 Kafka 中添加了新的特性，會帶來兩個主要的問題：

?Kafka 客戶端如何知道 Broker 這個新功能？?Broker 端如何決定啟用哪些功能？

KIP-584 為客戶端發現、功能識別和柔性升級提供了靈活和操作友好的解決方案，

KIP-554: 添加 Broker 端的 SCRAM 配置 API

通過 KIP-554, SCRAM 憑據可以通過 Kafka 協議進行管理，kafka-configs 工具使用了這個新的協議 API 以便在 Broker 端對 SCRAM 進行配置，這個也是 Kafka 移除 Zookeeper 專案的一部分，

KIP-497: 添加可以修改 ISR 的 Broker 內部 API

目前，Kafka partition leader 和 ISR 資訊存盤在 ZooKeeper 中，控制器或磁區 leader 都可以更新這個資訊，因為兩者都可以更新此狀態，所以需要有一種機制來共享此資訊，這可能會出現一方出現 ISR 資訊延遲，這些延遲的影響意味著元資料請求可能接收到舊的資訊，

在 2.7.0 版本中，添加了一個名為 AlterIsr 新的 API，它賦予 controller 獨家更新磁區 leader 和 ISR 狀態的能力，這個新 API 的主要好處是元資料請求將始侄訓取到最新的狀態，更多的資訊可以參見 KIP-497，

KIP-431: 使用 ConsoleConsumer 列印 Record 中的其他欄位

現在我們可以使用 ConsoleConsumer 列印 ConsumerRecord 中的頭資訊，具體細節可以參見 KIP-431，

Kafka Connect 的更新

KIP-632: 添加 DirectoryConfigProvider 類

KIP-632添加了 DirectoryConfigProvider 類，以支持需要為存盤在容器檔案系統（比如Kubernetes環境）中的密鑰提供保護的用戶，

Kafka Streams 的更新

KIP-662: 當 Kafka Streams 應用程式的源主題被洗掉時拋出例外

現在，如果用戶洗掉正在運行的 Kafka Streams 應用程式的源主題，其中的消費者客戶端會正常關閉，這個客戶端關閉觸發重新平衡，直到 Streams 應用程式的所有流執行緒優雅退出，使應用程式完全關閉，沒有任何方法來處理這個錯誤，這個版本添加了 KIP-662，當用戶從正在運行的 Streams 應用程式中洗掉源主題時，應用程式將拋出 MissingSourceTopicException，允許我們對錯誤作出反應，

KIP-648: 為互動式查詢重命名 getter 方法

KIP-648 改變了互動式查詢物件的 getter 方法，使其遵循不使用 get 前綴的 Kafka 格式，

KIP-617: 允許 Kafka Stream 狀態存盤向后迭代

目前，在 Kafka Streams 狀態存盤上使用迭代器時，只能從最老的元素遍歷到最新的元素，當迭代一個有視窗的狀態存盤時，如果用戶希望回傳最新的 N 條記錄，那么別無選擇，只能使用低效的方法，即遍歷所有最舊的記錄，然后再獲得所需的新記錄，KIP-617 增加了對反向狀態存盤迭代的支持，反向迭代使最新的N 條記錄檢索更加有效，

KIP-613: 添加了 Kafka Stream 端到端的延遲度量

目前，Kafka Stream 中訊息的實際端到端延遲是很難估計的，Kafka Stream 現在公開了端到端的指標，可以使得用戶在選型是做出更好的選擇，具體細節參見 KIP-613，

KIP-607: 在 Kafka Stream 中添加了 RocksDB 屬性相關的度量

當前 Kafka Stream 中 RocksDB 公開的指標不包括記憶體或磁盤使用情況，在 2.7.0 中，Kafka Stream 將 RocksDB 相關屬性也暴露出來了，具體細節參見 KIP-607，

KIP-450: DSL 中的滑動視窗支持聚合操作

Kafka Streams 實作了會話視窗（session windows），滾動視窗（tumbling windows）和跳躍視窗（hopping windows）作為視窗聚合方法，雖然提前時間較短的跳轉視窗可以模仿滑動視窗的行為，但這種實作的性能很差，因為它會導致許多重疊且經常是冗余的視窗，這需要昂貴的計算，不過，在 KIP-450 中，Kafka Stream 現在提供了一種有效的方式來世行滑動聚合，

Java與大資料架構

7年老碼農，10W+關注者，【Java與大資料架構】全面分享Java編程、Spark、Flink、Kafka、Elasticsearch、資料湖等干貨，歡迎掃碼關注！