點擊上方“朱小廝的博客”，選擇“設為星標”

后臺回復"書"，獲取

后臺回復“k8s”，可領取k8s資料

Apache Kafka 是一個分布式開源流平臺，被廣泛應用于各大互聯網公司。Kafka 設計之初被用于消息隊列，自 2011 年由 LinkedIn 開源以來，Kafka 迅速從消息隊列演變為成熟的事件流處理平臺。

Kafka 具有四個核心 API，借助這些 API，Kafka 可以用于以下兩大類應用：

• 建立實時流數據管道，可靠地進行數據傳輸，在系統或應用程序之間獲取數據。

• 構建實時流媒體應用程序，以改變系統或應用程序之間的數據或對數據流做出反應。
  

近日，Apache Kafka 3.0.0 正式發布，這是一個重要的版本更新，其中包括許多新的功能。

例如：

• 已棄用對 Java 8 和 Scala 2.12 的支持，對它們的支持將在 4.0 版本中徹底移除，以讓開發者有時間進行調整。

• Kafka Raft 支持元數據主題的快照，以及 self-managed quorum 方面的其他改進。

• 廢棄了消息格式 v0 和 v1。

• 默認情況下為 Kafka Producer 啟用更強的交付保證。

• 優化了 OffsetFetch 和 FindCoordinator 請求。

• 更靈活的 MirrorMaker 2 配置和 MirrorMaker 1 的棄用。

• 能夠在 Kafka Connect 的一次調用中重新啟動連接器的任務。

• 連接器日志上下文和連接器客戶端覆蓋現在是默認啟用的。

• 增強了 Kafka Streams 中時間戳同步的語義。

• 修改了 Stream 的 TaskId 的公共 API。

• 在 Kafka Streams 中，默認的 serde 變成了 null，還有一些其他的配置變化。

接下來，我們來看看新版本具體在哪些地方進行了更新。根據官方資料介紹，Apache Kafka 3.0 引入了各種新功能、突破性的 API 更改以及對 KRaft 的改進——Apache Kafka 的內置共識機制將取代 Apache ZooKeeper?。

雖然 KRaft 尚未被推薦用于生產（已知差距列表），但對 KRaft 元數據和 API 進行了許多改進。Exactly-once 和分區重新分配支持值得強調。鼓勵大家查看 KRaft 的新功能并在開發環境中試用它。

從 Apache Kafka 3.0 開始，生產者默認啟用最強的交付保證（acks=all， enable.idempotence=true）。這意味著用戶現在默認獲得排序和持久性。

此外，不要錯過 Kafka Connect 任務重啟增強、KStreams 基于時間戳同步的改進以及 MirrorMaker2 更靈活的配置選項。

常規變化

①KIP-750（第一部分）：棄用 Kafka 中對 Java 8 的支持

在 3.0 中，Apache Kafka 項目的所有組件都已棄用對 Java 8 的支持。這將使用戶有時間在下一個主要版本（4.0）之前進行調整，屆時 Java 8 支持將被取消。

②KIP-751（第一部分）：棄用 Kafka 中對 Scala 2.12 的支持

對 Scala 2.12 的支持在 Apache Kafka 3.0 中也已棄用。與 Java 8 一樣，我們給用戶時間來適應，因為計劃在下一個主要版本（4.0）中刪除對 Scala 2.12 的支持。

Kafka 代理、生產者、消費者和管理客戶端

①KIP-630：Kafka Raft 快照

我們在 3.0 中引入的一個主要功能是 KRaft 控制器和 KRaft 代理能夠為名為?__cluster_metadata 的元數據主題分區生成、復制和加載快照。

Kafka 集群使用此主題來存儲和復制有關集群的元數據信息，如代理配置、主題分區分配、領導等。

隨著此狀態的增長，Kafka Raft Snapshot 提供了一種有效的方式來存儲、加載和復制此信息。

②KIP-746：修改 KRaft 元數據記錄

自第一版 Kafka Raft 控制器以來的經驗和持續開發表明，需要修改一些元數據記錄類型，當 Kafka 被配置為在沒有 ZooKeeper（ZK）的情況下運行時使用這些記錄類型。

③KIP-730：KRaft 模式下的生產者 ID 生成

在 3.0 和 KIP-730 中，Kafka 控制器現在完全接管了生成 Kafka 生產者 ID 的責任。

控制器在 ZK 和 KRaft 模式下都這樣做。這讓我們更接近橋接版本，這將允許用戶從使用 ZK 的 Kafka 部署過渡到使用 KRaft 的新部署。

④KIP-679：Producer 將默認啟用最強的交付保證

從 3.0 開始，Kafka 生產者默認開啟冪等性和所有副本的交付確認。這使得默認情況下記錄交付保證更強。

⑤KIP-735：增加默認消費者會話超時

Kafka Consumer 的配置屬性的默認值 session.timeout.ms 從 10 秒增加到 45 秒。

這將允許消費者在默認情況下更好地適應暫時的網絡故障，并在消費者似乎只是暫時離開組時避免連續重新平衡。

⑥KIP-709：擴展 OffsetFetch 請求以接受多個組 ID

請求 Kafka 消費者組的當前偏移量已經有一段時間了。但是獲取多個消費者組的偏移量需要對每個組進行單獨的請求。

在 3.0 和 KIP-709 中，fetch 和 AdminClient API 被擴展為支持在單個請求/響應中同時讀取多個消費者組的偏移量。

⑦KIP-699：更新 FindCoordinator 以一次解析多個 Coordinator

支持可以以有效方式同時應用于多個消費者組的操作在很大程度上取決于客戶端有效發現這些組的協調者的能力。

這通過 KIP-699 成為可能，它增加了對通過一個請求發現多個組的協調器的支持。

Kafka 客戶端已更新為在與支持此請求的新 Kafka 代理交談時使用此優化。

⑧KIP-724：刪除對消息格式 v0 和 v1 的支持

自 2017 年 6 月隨 Kafka 0.11.0 推出四年以來，消息格式 v2 一直是默認消息格式。

因此，在橋下流過足夠多的水（或溪流）后，3.0 的主要版本為我們提供了棄用舊消息格式（即 v0 和 v1）的好機會。

這些格式今天很少使用。在 3.0 中，如果用戶將代理配置為使用消息格式 v0 或 v1，他們將收到警告。

此選項將在 Kafka 4.0 中刪除（有關詳細信息和棄用 v0 和 v1 消息格式的影響，請參閱 KIP-724）。

⑨KIP-707：KafkaFuture 的未來

當 KafkaFuture 引入該類型以促進 Kafka AdminClient 的實現時，Java 8 之前的版本仍在廣泛使用，并且 Kafka 正式支持 Java 7。

快進幾年后，現在 Kafka 運行在支持CompletionStage和 CompletableFuture 類類型的 Java 版本上。

使用 KIP-707，KafkaFuture 添加了一種返回 CompletionStage 對象的方法，并以 KafkaFuture 向后兼容的方式增強了可用性。

⑩KIP-466：添加對 List<T> 序列化和反序列化的支持

KIP-466為泛型列表的序列化和反序列化添加了新的類和方法——這一特性對 Kafka 客戶端和 Kafka Streams 都非常有用。

?KIP-734：改進 AdminClient.listOffsets 以返回時間戳和具有最大時間戳的記錄的偏移量

用戶列出 Kafka 主題/分區偏移量的功能已得到擴展。使用 KIP-734，用戶現在可以要求 AdminClient 返回主題/分區中具有最高時間戳的記錄的偏移量和時間戳。

這是不是與什么的 AdminClient 收益已經為最新的偏移，這是下一個記錄的偏移，在主題/分區寫入混淆。

這個擴展現有 ListOffsets API 允許用戶探測生動活潑的通過詢問哪個是最近寫入的記錄的偏移量以及它的時間戳是什么來分區。

Kafka Connect

①KIP-745：連接 API 以重新啟動連接器和任務

在 Kafka Connect 中，連接器在運行時表示為一組Connector類實例和一個或多個Task類實例，并且通過 Connect REST API 可用的連接器上的大多數操作都可以應用于整個組。

從一開始，一個值得注意的例外 restart 是 Connector 和 Task 實例的端點。要重新啟動整個連接器，用戶必須單獨調用以重新啟動連接器實例和任務實例。

在 3.0 中，KIP-745 使用戶能夠通過一次調用重新啟動所有或僅失敗的連接器 Connector 和 Task 實例。此功能是附加功能，restartREST API 的先前行為保持不變。

②KIP-738：刪除 Connect 的內部轉換器屬性

在之前的主版本（Apache Kafka 2.0）中棄用它們之后，internal.key.converter 并 internal.value.converter 在 Connect 工作器的配置中作為配置屬性和前綴被刪除。

展望未來，內部 Connect 主題將專門使用 JsonConverter 來存儲沒有嵌入模式的記錄。

任何使用不同轉換器的現有 Connect 集群都必須將其內部主題移植到新格式（有關升級路徑的詳細信息，請參閱 KIP-738）。

③KIP-722：默認啟用連接器客戶端覆蓋

從 Apache Kafka 2.3.0 開始，可以配置連接器工作器以允許連接器配置覆蓋連接器使用的 Kafka 客戶端屬性。

這是一個廣泛使用的功能，現在有機會發布一個主要版本，默認啟用覆蓋連接器客戶端屬性的功能（默認 connector.client.config.override.policy 設置為 All）。

④KIP-721：在連接 Log4j 配置中啟用連接器日志上下文

另一個在 2.3.0 中引入但到目前為止尚未默認啟用的功能是連接器日志上下文。這在 3.0 中發生了變化，連接器上下文默認添加 log4j 到 Connect 工作器的日志模式中。

從以前的版本升級到 3.0 將 log4j 通過在適當的情況下添加連接器上下文來更改導出的日志行的格式。

Kafka Streams

①KIP-695：進一步改進 Kafka Streams 時間戳同步

KIP-695 增強了 Streams 任務如何選擇獲取記錄的語義，并擴展了配置屬性的含義和可用值 max.task.idle.ms。

此更改需要 Kafka 消費者 API 中的一種新方法，currentLag 如果本地已知且無需聯系 Kafka Broker，則能夠返回特定分區的消費者滯后。

②KIP-715：在流中公開提交的偏移量

3.0 開始，三個新的方法添加到 TaskMetadata 接口：committedOffsets，endOffsets 和 timeCurrentIdlingStarted。這些方法可以允許 Streams 應用程序跟蹤其任務的進度和運行狀況。

③KIP-740：清理公共 API TaskId

KIP-740 代表了 TaskId 該類的重大革新。有幾種方法和所有內部字段已被棄用，新的 subtopology() 和 partition() 干將替換舊 topicGroupId 和 partition 字段（參見 KIP-744 的相關變化和修正 KIP-740）。

④KIP-744：遷移 TaskMetadata，并 ThreadMetadata 與內部實現的接口

KIP-744 將 KIP-740 提出的更改更進一步，并將實現與許多類的公共 API 分開。

為了實現這一點，引入了新的接口 TaskMetadata、ThreadMetadata 和 StreamsMetadata，而棄用了具有相同名稱的現有類。

⑤KIP-666：添加 Instant 基于方法到 ReadOnlySessionStore

交互式查詢 API 擴展了 ReadOnlySessionStore 和 SessionStore 接口中的一組新方法，這些方法接受 Instant 數據類型的參數。此更改將影響需要實現新方法的任何自定義只讀交互式查詢會話存儲實現。

⑥KIP-622：添加 currentSystemTimeMs 和 currentStreamTimeMs 到 ProcessorContext

該 ProcessorContext 增加在 3.0 兩個新的方法，currentSystemTimeMs 和 currentStreamTimeMs。

新方法使用戶能夠分別查詢緩存的系統時間和流時間，并且可以在生產和測試代碼中以統一的方式使用它們。

⑦KIP-743：刪除 0.10.0-2.4Streams 內置指標版本配置的配置值

3.0 中取消了對 Streams 中內置指標的舊指標結構的支持。KIP-743 正在 0.10.0-2.4 從配置屬性中刪除該值 built.in.metrics.version。

這 latest 是目前此屬性的唯一有效值（自 2.5 以來一直是默認值）。

⑧KIP-741：將默認 SerDe 更改為 null

刪除了默認 SerDe 屬性的先前默認值。流過去默認為 ByteArraySerde。

用 3.0 開始，沒有缺省，和用戶需要任一組其的 SerDes 根據需要在 API 中或通過設置默認 DEFAULT_KEY_SERDE_CLASS_CONFIG 和 DEFAULT_VALUE_SERDE_CLASS_CONFIG 在它們的流配置。

先前的默認值幾乎總是不適用于實際應用程序，并且造成的混亂多于方便。

⑨KIP-733：更改 Kafka Streams 默認復制因子配置

有了主要版本的機會，Streams 配置屬性的默認值replication.factor會從 1 更改為 -1。

這將允許新的 Streams 應用程序使用在 Kafka 代理中定義的默認復制因子，因此在它們轉移到生產時不需要設置此配置值。請注意，新的默認值需要 Kafka Brokers 2.5 或更高版本。

⑩KIP-732：棄用 eos-alpha 并用 eos-v2 替換 eos-beta

在 3.0 中不推薦使用的另一個 Streams 配置值是 exactly_once 作為屬性的值 processing.guarantee。

該值 exactly_once 對應于 Exactly Once Semantics (EOS) 的原始實現，可用于連接到 Kafka 集群版本 0.11.0 或更高版本的任何 Streams 應用程序。

此 EOS 的第一實現已經通過流第二實施 EOS 的，這是由值表示取代 exactly_once_beta 在 processing.guarantee 性質。

展望未來，該名稱 exactly_once_beta 也已棄用并替換為新名稱 exactly_once_v2。

在下一個主要版本（4.0）中，exactly_once 和 exactly_once_beta 都將被刪除，exactly_once_v2 作為 EOS 交付保證的唯一選項。

?KIP-725：優化 WindowedSerializer 和 WindowedDeserializer 的配置

配置屬性 default.windowed.key.serde.inner 和 default.windowed.value.serde.inner 已棄用。

取而代之的是 windowed.inner.class.serde 供消費者客戶端使用的單個新屬性。

建議 Kafka Streams 用戶通過將其傳遞到 SerDe 構造函數來配置他們的窗口化 SerDe，然后在拓撲中使用它的任何地方提供 SerDe。

?KIP-633：棄用 Streams 中寬限期的 24 小時默認值

在 Kafka Streams 中，允許窗口操作根據稱為寬限期的配置屬性處理窗口外的記錄。

以前，這個配置是可選的，很容易錯過，導致默認為 24 小時。這是 Suppression 運營商用戶經常感到困惑的原因，因為它會緩沖記錄直到寬限期結束，因此會增加 24 小時的延遲。

在 3.0 中，Windows 類通過工廠方法得到增強，這些工廠方法要求它們使用自定義寬限期或根本沒有寬限期來構造。已棄用默認寬限期為 24 小時的舊工廠方法，以及與 grace() 已設置此配置的新工廠方法不兼容的相應 API。

?KIP-623：internal-topics 為流應用程序重置工具添加“ ”選項

通過 kafka-streams-application-reset 添加新的命令行參數，應用程序重置工具的 Streams 使用變得更加靈活：--internal-topics。

新參數接受逗號分隔的主題名稱列表，這些名稱對應于可以使用此應用程序工具安排刪除的內部主題。

將此新參數與現有參數相結合，--dry-run 允許用戶在實際執行刪除操作之前確認將刪除哪些主題并在必要時指定它們的子集。

MirrorMaker

①KIP-720：棄用 MirrorMaker v1

在 3.0 中，不推薦使用 MirrorMaker 的第一個版本。展望未來，新功能的開發和重大改進將集中在 MirrorMaker 2（MM2）上。

②KIP-716：允許使用 MirrorMaker2 配置偏移同步主題的位置

在 3.0 中，用戶現在可以配置 MirrorMaker2 創建和存儲用于轉換消費者組偏移量的內部主題的位置。

這將允許 MirrorMaker2 的用戶將源 Kafka 集群維護為嚴格只讀的集群，并使用不同的 Kafka 集群來存儲偏移記錄（即目標 Kafka 集群，甚至是源和目標集群之外的第三個集群）。

Apache Kafka 3.0 是 Apache Kafka 項目向前邁出的重要一步。

更多詳情可查看：

https://blogs.apache.org/kafka

出處：內容來源于OSC開源社區（ID：oschina2013）、Flink（ID：Apache_Flink）

想知道更多？掃描下面的二維碼關注我后臺回復"技術"，加入技術群 后臺回復“k8s”，可領取k8s資料【精彩推薦】

• ClickHouse到底是什么？為什么如此牛逼！

• 原來ElasticSearch還可以這么理解

• 面試官：InnoDB中一棵B+樹可以存放多少行數據？

• 架構之道：分離業務邏輯和技術細節

• 星巴克不使用兩階段提交

• 面試官：Redis新版本開始引入多線程，談談你的看法？

• 喜馬拉雅自研網關架構演進過程

• 收藏：存儲知識全面總結

• 微博千萬級規模高性能高并發的網絡架構設計

總結

以上是生活随笔為你收集整理的Kafka 3.0重磅发布，都更新了些啥？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。