翻譯自 apache 官方宣告

我很自豪地代表Apache Kafka®社群宣佈Apache Kafka 2.7.0的釋出。2.7.0版本包含了許多新特性和改進。這篇部落格文章重點介紹了其中一些比較突出的功能。請務必檢視釋出說明以瞭解完整的變化列表。您也可以觀看釋出影片，瞭解新功能的概要。

在這個版本中，我們繼續朝著用KIP-497取代Kafka中的ZooKeeper的任務穩步前進，KIP-497增加了一個新的經紀商間API，用於改變同步內副本（ISR）。這個版本還提供了作為KIP-595的一部分的Core Raft實現的新增。現在有一個單獨的 "筏子 "模組，包含核心共識協議。在與控制器（Kafka叢集中負責管理分割槽和副本狀態的中介）的整合完成之前，有一個獨立的伺服器，你可以用來測試Raft實現的效能。

當然，還有更多的努力正在朝著取代Zookeeper的方向進行，7個KIP正在積極開發中，以提供對每個叢集更多分割槽的支援，更簡單的操作和更嚴格的安全性。

分層儲存工作仍在繼續，並透過KIP-405解鎖無限擴充套件和更快的再平衡時間。

Kafka經紀人、生產者和消費者

KIP-654: 含有非重新整理資料的中止事務應該丟擲一個非致命的異常。

當Java客戶端生產者在有任何非重新整理（掛起）資料的情況下中止一個事務時，會丟擲一個致命的異常。但是，在有待處理資料的情況下中止事務，實際上被認為是一種正常情況。丟擲的異常應該是通知你記錄沒有被髮送，而不是應用程式處於不可恢復的狀態。KIP-654引入了一個新的異常TransactionAbortedException，允許你在需要時重試。

KIP-651：支援私鑰和SSL證書和私鑰的PEM格式。

目前，Kafka在使用SSL時只支援基於JKS或PKCS12檔案的金鑰和信任儲存。雖然它不再是電子郵件的標準，但隱私增強郵件（PEM）是儲存和分發加密金鑰和證書的標準格式。KIP-651增加了對金鑰和信任儲存的PEM檔案的支援，允許使用依賴於PEM格式的第三方提供商。

KIP-612: 能夠限制經紀人的連線建立率

建立連線會給經紀人增加CPU開銷。連線風暴可能來自於看似乖巧的客戶端，並會阻止broker執行其他有用的工作。但現在有了一種方法來強制執行整個經紀商和每個監聽器的連線建立率。2.7.0 版本包含了 KIP-612 的第一部分，預計在 2.8.0 版本中會出現每個 IP 連線速率限制。

KIP-584: 功能的版本化方案

除了經紀商-客戶端的相容性（對於這一點，Kafka有很強的記錄來確保它們確實保持相容），當Kafka中出現新功能時，有兩個主要問題。

Kafka客戶如何意識到經紀人的功能？

經紀人如何決定啟用哪些功能？

KIP-584為客戶端發現、功能門控和滾動升級提供了一個靈活且操作友好的解決方案，使用一次重啟即可完成。

KIP-554：增加經紀商端SCRAM配置API。

透過KIP-554，SCRAM憑證可以透過Kafka協議進行管理，並且更新了kafka-configs工具以使用新引入的協議API。這是邁向KIP-500的另一個重要步驟，在KIP-500中，ZooKeeper被一個內建的quorum所取代。

KIP-497: 增加經紀人之間的API來改變ISR。

目前，Kafka分割槽領導和ISR資訊儲存在ZooKeeper中。無論是控制器還是分割槽領導都可以更新這些資訊。因為任何一個都可以更新這個狀態，所以需要有一個共享這個資訊的機制，這會導致反映ISR變化的延遲。這些延遲的影響意味著元資料請求可能會收到陳舊的資訊。

在2.7.0版本中，有一個新的AlterIsr API，它賦予控制器更新分割槽領導和ISR狀態的專屬能力。這個新API的主要好處是，元資料請求將始終反映最新狀態。

這個API的加入是在移除ZooKeeper和完成KIP-500的過程中邁出的重要一步。更多資訊，請參閱KIP-497。

KIP-431: 用 ConsoleConsumer 列印記錄中的附加欄位。

現在你可以用ConsoleConsumer在ConsumerRecord上列印頁首。更多細節請參見KIP-431。

Kafka連線

KIP-632: 新增DirectoryConfigProvider(目錄配置供應商)

KIP-632增加了一個DirectoryConfigProvider類，以支援使用者需要為儲存在容器檔案系統（如Kubernetes環境）中的金鑰提供秘密。

如今，如果使用者刪除了正在執行的Kafka Streams應用程式的源主題，嵌入式消費者客戶端就會優雅地關閉。這種客戶端關閉會觸發重新平衡，直到Streams應用程式的所有StreamThreads優雅地退出，使應用程式完全關閉，沒有任何機會響應錯誤。隨著KIP-662的加入，當用戶從正在執行的Streams應用程式中刪除一個源主題時，應用程式會丟擲一個MissingSourceTopicException，允許你對錯誤做出反應。

KIP-648：為互動式查詢重新命名getter方法。

KIP-648修改了互動式查詢物件的getter方法，使其遵循Kafka格式，不使用get字首。

KIP-617：允許Kafka Streams狀態儲存向後迭代。

目前，在Kafka Streams狀態儲存上使用迭代器時，只能從最舊到最新的元素進行遍歷。當在一個視窗化的狀態儲存上進行迭代，並且使用者希望返回最新的N條記錄時，除了使用在到達所需的較新記錄之前遍歷所有最舊的記錄這種低效率的方法外，別無選擇。KIP-617 增加了對狀態儲存的反向迭代的支援。反向迭代使得最新的 N 條記錄的檢索更加高效。

KIP-616: 重新命名 kafka-streams-scala 中的隱式 SerDes 例項。

Kafka Streams現在如何更好的用KIP-616支援Scala隱式Serdes。

KIP-613：為Kafka Streams新增端到端延遲指標。

目前，流經Kafka Streams的記錄的實際端到端延遲最多難以衡量。Kafka Streams現在公開了端到端指標，這將對使用者做出設計選擇有很大幫助。更多資訊請參見KIP-613。

KIP-607: 為Kafka Streams新增指標，報告RocksDB的屬性。

目前Kafka Streams為RocksDB暴露的指標不包括記憶體或磁碟使用情況的資訊。現在在2.7.0中，Kafka Streams報告RocksDB預設暴露的屬性。更多細節請參見KIP-607。

KIP-450: DSL中的滑動視窗聚合

Kafka Streams實現了會話視窗、翻滾視窗和跳轉視窗作為視窗化聚合方法。雖然提前時間較小的跳轉視窗可以模仿滑動視窗的行為，但這種實現的效能很差，因為它會導致許多重疊的、經常是冗餘的視窗，需要昂貴的計算。透過KIP-450增加滑動視窗後，Kafka Streams現在提供了一種高效的方法來執行滑動聚合。

要下載Apache Kafka 2.7.0，請訪問專案的下載頁面。