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：增加預設消費者會話超時
這將允許消費者在預設情況下更好地適應暫時的網路故障，並在消費者似乎只是暫時離開組時避免連續重新平衡。
⑥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
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 的內部轉換器屬性
展望未來，內部 Connect 主題將專門使用 JsonConverter 來儲存沒有嵌入模式的記錄。
任何使用不同轉換器的現有 Connect 叢集都必須將其內部主題移植到新格式（有關升級路徑的詳細資訊，請參閱 KIP-738）。
③KIP-722：預設啟用聯結器客戶端覆蓋
從 Apache Kafka 2。3。0 開始，可以配置聯結器工作器以允許聯結器配置覆蓋聯結器使用的 Kafka 客戶端屬性。
④KIP-721：在連線 Log4j 配置中啟用聯結器日誌上下文
另一個在 2。3。0 中引入但到目前為止尚未預設啟用的功能是聯結器日誌上下文。這在 3。0 中發生了變化，聯結器上下文預設新增 log4j 到 Connect 工作器的日誌模式中。
從以前的版本升級到 3。0 將 log4j 透過在適當的情況下新增聯結器上下文來更改匯出的日誌行的格式。
Kafka Streams
①KIP-695：進一步改進 Kafka Streams 時間戳同步
此更改需要 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 內建指標版本配置的配置值
這 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 的配置
建議 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 專案向前邁出的重要一步。
最近面試BAT，整理一份面試資料《
Java面試BATJ通關手冊
》，覆蓋了Java核心技術、JVM、Java併發、SSM、微服務、資料庫、資料結構等等。
文章有幫助的話，在看，轉發吧。
謝謝支援喲 （*^__^*）
