Kafka架構(gòu)技術(shù)：Kafka的架構(gòu)和客戶端API設(shè)計

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

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

我們來一起看看。

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

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

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

計算層

存儲層

計算層

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

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

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

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

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

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

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

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

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

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

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

存儲層

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

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

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

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

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

控制面板

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

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

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

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

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

下圖是一個示例。主題 "訂單"中的分區(qū) 0 在 3 個代理上有 3 個副本。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)地向兩個跟隨者發(fā)送數(shù)據(jù)。

第三步

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

編輯：黃飛