今天我們來聊一聊 Kafka 的架構。

大家一般熟悉的是三層結構：生產者、消費者、消息代理（Message Broker）。其實 Kafka 有更加詳細的架構。

我們來一起看看。

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

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

從高層次來看，架構分為兩層：

計算層

存儲層

計算層

計算層允許各種應用程序通過 API 與 Kafka Broker 通信。

生產者使用生產者 API。如果數據庫等外部系統想與 Kafka 通信，它還提供 Kafka Connect 作為集成 API。

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

此外，消費者還可以使用 Kafka Streams API 進行流式處理。如果要處理無邊界的數據流，我們可以創建一個 KStream。

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

如果我們只需要更新實體的最新狀態，我們可以創建一個 KTable 來維護狀態。

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

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

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

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

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

存儲層

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

主題就像一個數據庫表，主題中的分區可以分布在不同的集群節點上。在分區內，事件嚴格按照偏移量（offset）排序。偏移量代表事件在分區中的位置，并單調遞增。

在 Broker 上持久化的事件是不可變的（immutable）、只可追加的（append only），即使是刪除也被模擬為刪除事件，而不是直接從磁盤上刪除數據。因此，生產者只能處理順序寫入，消費者只能順序讀取。

Kafka Broker 的職責包括管理分區、處理讀寫操作以及管理分區的數據復制。它的設計非常簡單，因此易于擴展。

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

控制面板

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

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

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

數據面板

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

下圖是一個示例。主題 "訂單"中的分區 0 在 3 個代理上有 3 個副本。Broker 1 上的分區是領導者（leader），當前數據偏移量為 4；Broker 2 和 3 上的分區是跟隨者（follower），偏移量分別為 2 和 3。

第一步

為了趕上領導者，跟隨者 1 發出偏移量為 2 的 FetchRequest，跟隨者 2 發出偏移量為 3 的 FetchRequest。

第二步

然后，領導者相應地向兩個跟隨者發送數據。

第三步

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

編輯：黃飛