123,123

[導(dǎo)讀]來(lái)源：OSC開(kāi)源社區(qū)（ID：oschina2013）Flink（ID：Apache_Flink）ApacheKafka是一個(gè)分布式開(kāi)源流平臺(tái)，被廣泛應(yīng)用于各大互聯(lián)網(wǎng)公司。Kafka設(shè)計(jì)之初被用于消息隊(duì)列，自2011年由LinkedIn開(kāi)源以來(lái)，Kafka迅速?gòu)南㈥?duì)列演變?yōu)槌墒斓?..

來(lái)源：OSC開(kāi)源社區(qū)（ID：oschina2013）Flink（ID：Apache_Flink）

Apache Kafka 是一個(gè)分布式開(kāi)源流平臺(tái)，被廣泛應(yīng)用于各大互聯(lián)網(wǎng)公司。Kafka 設(shè)計(jì)之初被用于消息隊(duì)列，自 2011 年由 LinkedIn 開(kāi)源以來(lái)，Kafka 迅速?gòu)南㈥?duì)列演變?yōu)槌墒斓氖录魈幚砥脚_(tái)。

Kafka 具有四個(gè)核心 API，借助這些 API，Kafka 可以用于以下兩大類(lèi)應(yīng)用：

建立實(shí)時(shí)流數(shù)據(jù)管道，可靠地進(jìn)行數(shù)據(jù)傳輸，在系統(tǒng)或應(yīng)用程序之間獲取數(shù)據(jù)。
構(gòu)建實(shí)時(shí)流媒體應(yīng)用程序，以改變系統(tǒng)或應(yīng)用程序之間的數(shù)據(jù)或?qū)?shù)據(jù)流做出反應(yīng)。

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

例如：

已棄用對(duì) Java 8 和 Scala 2.12 的支持，對(duì)它們的支持將在 4.0 版本中徹底移除，以讓開(kāi)發(fā)者有時(shí)間進(jìn)行調(diào)整。
Kafka Raft 支持元數(shù)據(jù)主題的快照，以及 self-managed quorum 方面的其他改進(jìn)。
廢棄了消息格式 v0 和 v1。
默認(rèn)情況下為 Kafka Producer 啟用更強(qiáng)的交付保證。
優(yōu)化了 OffsetFetch 和 FindCoordinator 請(qǐng)求。
更靈活的 MirrorMaker 2 配置和 MirrorMaker 1 的棄用。
能夠在 Kafka Connect 的一次調(diào)用中重新啟動(dòng)連接器的任務(wù)。
連接器日志上下文和連接器客戶(hù)端覆蓋現(xiàn)在是默認(rèn)啟用的。
增強(qiáng)了 Kafka Streams 中時(shí)間戳同步的語(yǔ)義。
修改了 Stream 的 TaskId 的公共 API。
在 Kafka Streams 中，默認(rèn)的 serde 變成了 null，還有一些其他的配置變化。

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

雖然 KRaft 尚未被推薦用于生產(chǎn)（已知差距列表），但對(duì) KRaft 元數(shù)據(jù)和 API 進(jìn)行了許多改進(jìn)。Exactly-once 和分區(qū)重新分配支持值得強(qiáng)調(diào)。鼓勵(lì)大家查看 KRaft 的新功能并在開(kāi)發(fā)環(huán)境中試用它。

從 Apache Kafka 3.0 開(kāi)始，生產(chǎn)者默認(rèn)啟用最強(qiáng)的交付保證（acks=all， enable.idempotence=true）。這意味著用戶(hù)現(xiàn)在默認(rèn)獲得排序和持久性。

此外，不要錯(cuò)過(guò) Kafka Connect 任務(wù)重啟增強(qiáng)、KStreams 基于時(shí)間戳同步的改進(jìn)以及 MirrorMaker2 更靈活的配置選項(xiàng)。

| 常規(guī)變化

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

在 3.0 中，Apache Kafka 項(xiàng)目的所有組件都已棄用對(duì) Java 8 的支持。這將使用戶(hù)有時(shí)間在下一個(gè)主要版本（4.0）之前進(jìn)行調(diào)整，屆時(shí) Java 8 支持將被取消。

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

對(duì) Scala 2.12 的支持在 Apache Kafka 3.0 中也已棄用。與 Java 8 一樣，我們給用戶(hù)時(shí)間來(lái)適應(yīng)，因?yàn)橛?jì)劃在下一個(gè)主要版本（4.0）中刪除對(duì) Scala 2.12 的支持。| Kafka 代理、生產(chǎn)者、消費(fèi)者和管理客戶(hù)端

KIP-630：Kafka Raft 快照

我們?cè)?3.0 中引入的一個(gè)主要功能是 KRaft 控制器和 KRaft 代理能夠?yàn)槊麨?__cluster_metadata 的元數(shù)據(jù)主題分區(qū)生成、復(fù)制和加載快照。

Kafka 集群使用此主題來(lái)存儲(chǔ)和復(fù)制有關(guān)集群的元數(shù)據(jù)信息，如代理配置、主題分區(qū)分配、領(lǐng)導(dǎo)等。

隨著此狀態(tài)的增長(zhǎng)，Kafka Raft Snapshot 提供了一種有效的方式來(lái)存儲(chǔ)、加載和復(fù)制此信息。

KIP-746：修改 KRaft 元數(shù)據(jù)記錄

自第一版 Kafka Raft 控制器以來(lái)的經(jīng)驗(yàn)和持續(xù)開(kāi)發(fā)表明，需要修改一些元數(shù)據(jù)記錄類(lèi)型，當(dāng) Kafka 被配置為在沒(méi)有 ZooKeeper（ZK）的情況下運(yùn)行時(shí)使用這些記錄類(lèi)型。

KIP-730：KRaft 模式下的生產(chǎn)者 ID 生成

在 3.0 和 KIP-730 中，Kafka 控制器現(xiàn)在完全接管了生成 Kafka 生產(chǎn)者 ID 的責(zé)任。

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

KIP-679：Producer 將默認(rèn)啟用最強(qiáng)的交付保證

從 3.0 開(kāi)始，Kafka 生產(chǎn)者默認(rèn)開(kāi)啟冪等性和所有副本的交付確認(rèn)。這使得默認(rèn)情況下記錄交付保證更強(qiáng)。

KIP-735：增加默認(rèn)消費(fèi)者會(huì)話(huà)超時(shí)

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

這將允許消費(fèi)者在默認(rèn)情況下更好地適應(yīng)暫時(shí)的網(wǎng)絡(luò)故障，并在消費(fèi)者似乎只是暫時(shí)離開(kāi)組時(shí)避免連續(xù)重新平衡。

KIP-709：擴(kuò)展 OffsetFetch 請(qǐng)求以接受多個(gè)組 ID

請(qǐng)求 Kafka 消費(fèi)者組的當(dāng)前偏移量已經(jīng)有一段時(shí)間了。但是獲取多個(gè)消費(fèi)者組的偏移量需要對(duì)每個(gè)組進(jìn)行單獨(dú)的請(qǐng)求。

在 3.0 和 KIP-709 中，fetch 和 AdminClient API 被擴(kuò)展為支持在單個(gè)請(qǐng)求/響應(yīng)中同時(shí)讀取多個(gè)消費(fèi)者組的偏移量。

KIP-699：更新 FindCoordinator 以一次解析多個(gè) Coordinator

支持可以以有效方式同時(shí)應(yīng)用于多個(gè)消費(fèi)者組的操作在很大程度上取決于客戶(hù)端有效發(fā)現(xiàn)這些組的協(xié)調(diào)者的能力。

這通過(guò) KIP-699 成為可能，它增加了對(duì)通過(guò)一個(gè)請(qǐng)求發(fā)現(xiàn)多個(gè)組的協(xié)調(diào)器的支持。

Kafka 客戶(hù)端已更新為在與支持此請(qǐng)求的新 Kafka 代理交談時(shí)使用此優(yōu)化。

KIP-724：刪除對(duì)消息格式 v0 和 v1 的支持

自 2017 年 6 月隨 Kafka 0.11.0 推出四年以來(lái)，消息格式 v2 一直是默認(rèn)消息格式。

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

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

此選項(xiàng)將在 Kafka 4.0 中刪除（有關(guān)詳細(xì)信息和棄用 v0 和 v1 消息格式的影響，請(qǐng)參閱 KIP-724）。

KIP-707：KafkaFuture 的未來(lái)

當(dāng) KafkaFuture 引入該類(lèi)型以促進(jìn) Kafka AdminClient 的實(shí)現(xiàn)時(shí)，Java 8 之前的版本仍在廣泛使用，并且 Kafka 正式支持 Java 7。

快進(jìn)幾年后，現(xiàn)在 Kafka 運(yùn)行在支持CompletionStage和 CompletableFuture 類(lèi)類(lèi)型的 Java 版本上。

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

KIP-466：添加對(duì) List序列化和反序列化的支持

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

KIP-734：改進(jìn) AdminClient.listOffsets 以返回時(shí)間戳和具有最大時(shí)間戳的記錄的偏移量

用戶(hù)列出 Kafka 主題/分區(qū)偏移量的功能已得到擴(kuò)展。使用 KIP-734，用戶(hù)現(xiàn)在可以要求 AdminClient 返回主題/分區(qū)中具有最高時(shí)間戳的記錄的偏移量和時(shí)間戳。

這是不是與什么的 AdminClient 收益已經(jīng)為最新的偏移，這是下一個(gè)記錄的偏移，在主題/分區(qū)寫(xiě)入混淆。

這個(gè)擴(kuò)展現(xiàn)有 ListOffsets API 允許用戶(hù)探測(cè)生動(dòng)活潑的通過(guò)詢(xún)問(wèn)哪個(gè)是最近寫(xiě)入的記錄的偏移量以及它的時(shí)間戳是什么來(lái)分區(qū)。| Kafka Connect

KIP-745：連接 API 以重新啟動(dòng)連接器和任務(wù)

在 Kafka Connect 中，連接器在運(yùn)行時(shí)表示為一組Connector類(lèi)實(shí)例和一個(gè)或多個(gè)Task類(lèi)實(shí)例，并且通過(guò) Connect REST API 可用的連接器上的大多數(shù)操作都可以應(yīng)用于整個(gè)組。

從一開(kāi)始，一個(gè)值得注意的例外 restart 是 Connector 和 Task 實(shí)例的端點(diǎn)。要重新啟動(dòng)整個(gè)連接器，用戶(hù)必須單獨(dú)調(diào)用以重新啟動(dòng)連接器實(shí)例和任務(wù)實(shí)例。

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

KIP-738：刪除 Connect 的內(nèi)部轉(zhuǎn)換器屬性

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

展望未來(lái)，內(nèi)部 Connect 主題將專(zhuān)門(mén)使用 JsonConverter 來(lái)存儲(chǔ)沒(méi)有嵌入模式的記錄。

任何使用不同轉(zhuǎn)換器的現(xiàn)有 Connect 集群都必須將其內(nèi)部主題移植到新格式（有關(guān)升級(jí)路徑的詳細(xì)信息，請(qǐng)參閱 KIP-738）。

KIP-722：默認(rèn)啟用連接器客戶(hù)端覆蓋

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

這是一個(gè)廣泛使用的功能，現(xiàn)在有機(jī)會(huì)發(fā)布一個(gè)主要版本，默認(rèn)啟用覆蓋連接器客戶(hù)端屬性的功能（默認(rèn) connector.client.config.override.policy 設(shè)置為 All）。

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

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

從以前的版本升級(jí)到 3.0 將 log4j 通過(guò)在適當(dāng)?shù)那闆r下添加連接器上下文來(lái)更改導(dǎo)出的日志行的格式。

| Kafka Streams

KIP-695：進(jìn)一步改進(jìn) Kafka Streams 時(shí)間戳同步

KIP-695 增強(qiáng)了 Streams 任務(wù)如何選擇獲取記錄的語(yǔ)義，并擴(kuò)展了配置屬性的含義和可用值 max.task.idle.ms。

此更改需要 Kafka 消費(fèi)者 API 中的一種新方法，currentLag 如果本地已知且無(wú)需聯(lián)系 Kafka Broker，則能夠返回特定分區(qū)的消費(fèi)者滯后。

KIP-715：在流中公開(kāi)提交的偏移量

3.0 開(kāi)始，三個(gè)新的方法添加到 TaskMetadata 接口：committedOffsets，endOffsets 和 timeCurrentIdlingStarted。這些方法可以允許 Streams 應(yīng)用程序跟蹤其任務(wù)的進(jìn)度和運(yùn)行狀況。

KIP-740：清理公共 API TaskId

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

KIP-744：遷移 TaskMetadata，并 ThreadMetadata 與內(nèi)部實(shí)現(xiàn)的接口

KIP-744 將 KIP-740 提出的更改更進(jìn)一步，并將實(shí)現(xiàn)與許多類(lèi)的公共 API 分開(kāi)。

為了實(shí)現(xiàn)這一點(diǎn)，引入了新的接口 TaskMetadata、ThreadMetadata 和 StreamsMetadata，而棄用了具有相同名稱(chēng)的現(xiàn)有類(lèi)。

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

交互式查詢(xún) API 擴(kuò)展了 ReadOnlySessionStore 和 SessionStore 接口中的一組新方法，這些方法接受 Instant 數(shù)據(jù)類(lèi)型的參數(shù)。此更改將影響需要實(shí)現(xiàn)新方法的任何自定義只讀交互式查詢(xún)會(huì)話(huà)存儲(chǔ)實(shí)現(xiàn)。

KIP-622：添加 currentSystemTimeMs 和 currentStreamTimeMs 到 ProcessorContext

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

新方法使用戶(hù)能夠分別查詢(xún)緩存的系統(tǒng)時(shí)間和流時(shí)間，并且可以在生產(chǎn)和測(cè)試代碼中以統(tǒng)一的方式使用它們。

KIP-743：刪除 0.10.0-2.4Streams 內(nèi)置指標(biāo)版本配置的配置值

3.0 中取消了對(duì) Streams 中內(nèi)置指標(biāo)的舊指標(biāo)結(jié)構(gòu)的支持。KIP-743 正在 0.10.0-2.4 從配置屬性中刪除該值 built.in.metrics.version。

這 latest 是目前此屬性的唯一有效值（自 2.5 以來(lái)一直是默認(rèn)值）。

KIP-741：將默認(rèn) SerDe 更改為 null

刪除了默認(rèn) SerDe 屬性的先前默認(rèn)值。流過(guò)去默認(rèn)為 ByteArraySerde。

用 3.0 開(kāi)始，沒(méi)有缺省，和用戶(hù)需要任一組其的 SerDes 根據(jù)需要在 API 中或通過(guò)設(shè)置默認(rèn) DEFAULT_KEY_SERDE_CLASS_CONFIG 和 DEFAULT_VALUE_SERDE_CLASS_CONFIG 在它們的流配置。

先前的默認(rèn)值幾乎總是不適用于實(shí)際應(yīng)用程序，并且造成的混亂多于方便。

KIP-733：更改 Kafka Streams 默認(rèn)復(fù)制因子配置

有了主要版本的機(jī)會(huì)，Streams 配置屬性的默認(rèn)值replication.factor會(huì)從 1 更改為 -1。

這將允許新的 Streams 應(yīng)用程序使用在 Kafka 代理中定義的默認(rèn)復(fù)制因子，因此在它們轉(zhuǎn)移到生產(chǎn)時(shí)不需要設(shè)置此配置值。請(qǐng)注意，新的默認(rèn)值需要 Kafka Brokers 2.5 或更高版本。

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

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

該值 exactly_once 對(duì)應(yīng)于 Exactly Once Semantics (EOS) 的原始實(shí)現(xiàn)，可用于連接到 Kafka 集群版本 0.11.0 或更高版本的任何 Streams 應(yīng)用程序。

此 EOS 的第一實(shí)現(xiàn)已經(jīng)通過(guò)流第二實(shí)施 EOS 的，這是由值表示取代 exactly_once_beta 在 processing.guarantee 性質(zhì)。

展望未來(lái)，該名稱(chēng) exactly_once_beta 也已棄用并替換為新名稱(chēng) exactly_once_v2。

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

KIP-725：優(yōu)化 WindowedSerializer 和 WindowedDeserializer 的配置

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

取而代之的是 windowed.inner.class.serde 供消費(fèi)者客戶(hù)端使用的單個(gè)新屬性。

建議 Kafka Streams 用戶(hù)通過(guò)將其傳遞到 SerDe 構(gòu)造函數(shù)來(lái)配置他們的窗口化 SerDe，然后在拓?fù)渲惺褂盟娜魏蔚胤教峁?SerDe。

KIP-633：棄用 Streams 中寬限期的 24 小時(shí)默認(rèn)值

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

以前，這個(gè)配置是可選的，很容易錯(cuò)過(guò)，導(dǎo)致默認(rèn)為 24 小時(shí)。這是 Suppression 運(yùn)營(yíng)商用戶(hù)經(jīng)常感到困惑的原因，因?yàn)樗鼤?huì)緩沖記錄直到寬限期結(jié)束，因此會(huì)增加 24 小時(shí)的延遲。

在 3.0 中，Windows 類(lèi)通過(guò)工廠方法得到增強(qiáng)，這些工廠方法要求它們使用自定義寬限期或根本沒(méi)有寬限期來(lái)構(gòu)造。已棄用默認(rèn)寬限期為 24 小時(shí)的舊工廠方法，以及與 grace() 已設(shè)置此配置的新工廠方法不兼容的相應(yīng) API。