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

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

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

我們來一起看看。

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

下圖詳細展示了 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 進行流式處理。如果要處理無邊界的數(shù)據(jù)流，我們可以創(chuàng)建一個 KStream。

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

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

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

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

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

我們可以看到，有了計算層中的各種 API 支持，我們可以非常靈活地對事件流進行鏈式操作。

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

存儲層

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

主題就像一個數(shù)據(jù)庫表，主題中的分區(qū)可以分布在不同的集群節(jié)點上。在分區(qū)內(nèi)，事件嚴格按照偏移量（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 時，我們需要維護兩個不同類型的系統(tǒng)：一個是 Zookeeper，另一個是 Kafka。有了 KRaft，我們只需維護一種類型的系統(tǒng)，這使得配置和部署比以前容易得多。此外，KRaft 在向 Broker 傳播元數(shù)據(jù)方面效率更高。

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

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

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

下圖是一個示例。主題 "訂單"中的分區(qū) 0 在 3 個代理上有 3 個副本。Broker 1 上的分區(qū)是領(lǐng)導(dǎo)者（leader），當前數(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ù)。

第三步

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

編輯：黃飛