今天我們來(lái)聊一聊 Kafka 的架構(gòu)。

大家一般熟悉的是三層結(jié)構(gòu)：生產(chǎn)者、消費(fèi)者、消息代理（Message Broker）。其實(shí) Kafka 有更加詳細(xì)的架構(gòu)。

我們來(lái)一起看看。

Kafka 給自己的定位是事件流平臺(tái)（event stream platform）。因此在消息隊(duì)列中經(jīng)常使用的 "消息"一詞，在 Kafka 中被稱為 "事件"。

下圖詳細(xì)展示了 Kafka 的架構(gòu)和客戶端 API 設(shè)計(jì)。我們可以看到，盡管生產(chǎn)者、消費(fèi)者和消息代理仍然是架構(gòu)的關(guān)鍵，但要構(gòu)建一個(gè)高吞吐量、低時(shí)延的 Kafka，還需要更多的組件。讓我們逐一介紹這些組件。

從高層次來(lái)看，架構(gòu)分為兩層：

計(jì)算層

存儲(chǔ)層

計(jì)算層

計(jì)算層允許各種應(yīng)用程序通過(guò) API 與 Kafka Broker 通信。

生產(chǎn)者使用生產(chǎn)者 API。如果數(shù)據(jù)庫(kù)等外部系統(tǒng)想與 Kafka 通信，它還提供 Kafka Connect 作為集成 API。

消費(fèi)者通過(guò)消費(fèi)者 API 與 Broker 通信。我們可以使用 Kafka Connect API 將事件數(shù)據(jù)路由到其他數(shù)據(jù)處理平臺(tái)上，例如搜索引擎或數(shù)據(jù)庫(kù)。

此外，消費(fèi)者還可以使用 Kafka Streams API 進(jìn)行流式處理。如果要處理無(wú)邊界的數(shù)據(jù)流，我們可以創(chuàng)建一個(gè) KStream。

下面的代碼片段為主題 "訂單 "創(chuàng)建了一個(gè) KStream，并為 key 和 value 創(chuàng)建了 Serdes（Serializers and Deserializers，序列化和反序列化）。

如果我們只需要更新實(shí)體的最新狀態(tài)，我們可以創(chuàng)建一個(gè) KTable 來(lái)維護(hù)狀態(tài)。

Kafka Streams 允許我們對(duì)事件流進(jìn)行聚合、過(guò)濾、分組和連接。

finalKStreamBuilderbuilder=newKStreamBuilder();
finalKStreamorderEvents=
builder.stream(Serdes.String(),orderEventSerde,"orders");

雖然 Kafka Streams API 在 Java 應(yīng)用程序中運(yùn)行良好，但有時(shí)我們可能希望部署一個(gè)獨(dú)立的流處理模塊，而不將其嵌入到應(yīng)用程序中。這時(shí)，我們可以使用 ksqlDB。這是一個(gè)針對(duì)流處理進(jìn)行了優(yōu)化的數(shù)據(jù)庫(kù)集群。它還提供了 REST API，供我們查詢結(jié)果。

我們可以看到，有了計(jì)算層中的各種 API 支持，我們可以非常靈活地對(duì)事件流進(jìn)行鏈?zhǔn)讲僮鳌?/p>

例如，我們可以在消費(fèi)者中訂閱主題 "orders"，按照產(chǎn)品維度進(jìn)行訂單聚合，然后將每個(gè)產(chǎn)品的訂單數(shù)發(fā)回 Kafka 主題 "ordersByProduct"；另一個(gè)分析模塊可以訂閱這個(gè)主題并在界面上顯示這些訂單。

存儲(chǔ)層

這一層由 Kafka Broker 組成。Kafka Broker 以集群模式運(yùn)行。數(shù)據(jù)存儲(chǔ)在不同主題的分區(qū)中。

主題就像一個(gè)數(shù)據(jù)庫(kù)表，主題中的分區(qū)可以分布在不同的集群節(jié)點(diǎn)上。在分區(qū)內(nèi)，事件嚴(yán)格按照偏移量（offset）排序。偏移量代表事件在分區(qū)中的位置，并單調(diào)遞增。

在 Broker 上持久化的事件是不可變的（immutable）、只可追加的（append only），即使是刪除也被模擬為刪除事件，而不是直接從磁盤上刪除數(shù)據(jù)。因此，生產(chǎn)者只能處理順序?qū)懭耄M(fèi)者只能順序讀取。

Kafka Broker 的職責(zé)包括管理分區(qū)、處理讀寫操作以及管理分區(qū)的數(shù)據(jù)復(fù)制。它的設(shè)計(jì)非常簡(jiǎn)單，因此易于擴(kuò)展。

由于 Kafka Broker 是以集群模式部署的，因此有兩個(gè)必要的組件來(lái)管理節(jié)點(diǎn)：控制面板和數(shù)據(jù)面板。

控制面板

控制平面管理 Kafka 集群的元數(shù)據(jù)。以前的版本中是由 Zookeeper 來(lái)管理控制器：挑選一個(gè) Broker 作為控制器（Controller）。現(xiàn)在，Kafka 使用名為 KRaft 的共識(shí)模塊來(lái)實(shí)現(xiàn)控制面板，選取幾個(gè) Broker 做為控制器。

為什么不再依賴 Zookeeper？因?yàn)槭褂?Zookeeper 時(shí)，我們需要維護(hù)兩個(gè)不同類型的系統(tǒng)：一個(gè)是 Zookeeper，另一個(gè)是 Kafka。有了 KRaft，我們只需維護(hù)一種類型的系統(tǒng)，這使得配置和部署比以前容易得多。此外，KRaft 在向 Broker 傳播元數(shù)據(jù)方面效率更高。

我們不會(huì)在這里討論 KRaft 共識(shí)的細(xì)節(jié)。需要記住的一點(diǎn)是，控制器和 Broker 中的元數(shù)據(jù)緩存是通過(guò) Kafka 中的一個(gè)特殊主題同步的。

數(shù)據(jù)面板

數(shù)據(jù)面板處理數(shù)據(jù)的復(fù)制操作。單個(gè)分區(qū)的數(shù)據(jù)可以在不同的 Broker 上有多份拷貝，這些拷貝之間需要進(jìn)行數(shù)據(jù)同步。

下圖是一個(gè)示例。主題 "訂單"中的分區(qū) 0 在 3 個(gè)代理上有 3 個(gè)副本。Broker 1 上的分區(qū)是領(lǐng)導(dǎo)者（leader），當(dāng)前數(shù)據(jù)偏移量為 4；Broker 2 和 3 上的分區(qū)是跟隨者（follower），偏移量分別為 2 和 3。

第一步

為了趕上領(lǐng)導(dǎo)者，跟隨者 1 發(fā)出偏移量為 2 的 FetchRequest，跟隨者 2 發(fā)出偏移量為 3 的 FetchRequest。

第二步

然后，領(lǐng)導(dǎo)者相應(yīng)地向兩個(gè)跟隨者發(fā)送數(shù)據(jù)。

第三步

由于跟隨者的請(qǐng)求隱含地確認(rèn)了先前獲取記錄的接收情況，因此領(lǐng)導(dǎo)者會(huì)將偏移量 2 之前的記錄提交。

編輯：黃飛