了解了 Kafka 架構就掌握了 Kafka 最核心的知識，Kafka 作為業界最知名、最流行的訊息系統和流式處理元件，在面試中和日常工作中經常會見到，那麽今天，我們就來聊聊 Kafka 的架構演化與升級，並透過圖解的方式讓你一目了然。
1.Kafka 初印象
Kafka 最初由 LinkedIn 公司開發，後來成為了 Apache 軟件基金會的一個開源專案。它的主要設計目標是提供一個高吞吐量、可持久化、分布式的訊息系統。
2.Kafka 基礎架構
Kafka 最簡單的基礎架構如下：
Kafka 主要是由以下 4 部份組成：
- Producer（生產者） ：訊息發送方，生產者負責建立訊息，然後將其投遞到 Kafka（Broker）中。
- Consumer（消費者） ：接收訊息方，消費者連線到 Kafka 上並接收訊息，進而進行相應的業務邏輯處理。
- Broker（代理） ：一個 Broker 可以簡單地看作一個獨立的 Kafka 服務節點或 Kafka 服務例項。大多數情況下也可以將 Broker 看作一台 Kafka 伺服器，前提是這台伺服器上只部署了一個 Kafka 例項。一個或多個 Broker 組成了一個 Kafka 集群。一般而言，我們更習慣使用首字母小寫的 broker 來表示服務代理節點。
- ZooKeeper ：ZooKeeper 是 Kafka（集群）中使用的分布式協調服務，用於維護 Kafka（集群）的狀態和後設資料資訊，例如主題和分區的分配資訊、消費者組和消費者偏移量等資訊。
Kafka 2.8.0 之後，Kafka 引入了 KRaft（Kafka Raft）模式，它提供了一種新的內建的共識機制來替代對 Zookeeper 的依賴。此時，Kafka 可以脫離 Zookeeper 單獨執行，但需要配置 KRaft 控制器才行，Kafka 預設服務還是要配合 Zookeeper 執行的。
3.不同的訊息類別怎麽辦？
在上述最基礎的 Kafka 架構中我們會發現一個問題，那就是如果是不同的訊息類別要怎麽辦？例如以下情況：
此時，我們可以把不同類別的訊息存放在一起，但這樣就需要給訊息添加 type 欄位，以區分不同的訊息。
但添加了 type 欄位之後，後面的維護和擴充套件又不方便，而且 type 越多，程式碼中的判斷程式碼就越復雜，想象一下： 一個復雜專案的訊息類別是有成千上萬個分類的，那我們的判斷程式碼也要寫成千上萬個 if-else 判斷不可 ？這要怎麽解決呢？
這時候，我們就需要一個「訊息分類機制」，這個機制在 Kafka 裏被稱之為 Topic（主題），如下圖所示：
引入了 Topic 之後，不同的訊息就可以發送到不同的 Topic 了，不同業務的生產者和消費者就可以實作相互隔離、互不影響了。
Broker 和 Topic 的關系： 一個 Broker 中可以包含多個 Topic 。
4.如何保證高效能？
4.1 數據分片
想要提升 Kafka 效能就需要水平擴充套件 Broker 數量，如下圖所示：
在 Kafka 中，Topic 是用 Partition（分區）儲存的，所以它正確的互動流程如下所示：
這小節核心知識點：
- Partition（分區）就是真正儲存數據的 訊息佇列 。
- 有了集群和多個 Partition 之後，Kafka 的數據就可以實作分片儲存了，效能也得到很大的提升。
什麽是數據分片？
數據分片儲存是一種將大量數據分散儲存在多個不同位置或器材上的技術。
在數據量龐大的情況下，為了提高數據的儲存效率、存取效能和可延伸性，將數據分割成較小的片段，然後分別儲存在不同的節點或儲存器材中。
以下是一些數據分片儲存的特點和優勢：
- 提高效能 ：透過將數據分散儲存，可以並列地處理數據請求，從而加快數據的讀取和寫入速度。例如，在一個分布式數據庫中，不同的分片可以同時響應查詢，減少了總體的響應時間。
- 增強可延伸性 ：當數據量不斷增長時，可以方便地添加更多的分片來擴充套件儲存容量，而無需對整個系統進行大規模的重構。
- 避免單點效能瓶頸 ：數據分片可以使數據的儲存和存取負載更加均衡地分布在多個節點上，避免單個節點成為效能瓶頸。
4.2 消費組
如果沒有消費組，那麽一個 Topic 只能被一個消費者消費，效能會很低，如下圖所示：
消費組（Consumer Group）是一個由多個消費者（Consumer）組成的邏輯概念，用於實作對一個主題（Topic）中訊息進行並行消費和負載均衡的機制。
特性分析
Kafka 消費組特性如下：
- 並行執行 ：將一個主題內的訊息分給多個消費者並行處理，提升了訊息消費的效能。
- 容錯性好 ：如果組內的某個消費者發生故障，Kafka 能夠自動地將該消費者負責的分區重新分配給其他健康的消費者，確保訊息不會被遺漏。
- 支持多種消費模式 ：透過調整消費者組的配置，可以 實作不同的消費模式 ，如釋出訂閱模式（一對多）和佇列模式（一對一）。在釋出訂閱模式下，一個訊息可以被多個消費者組同時消費，每個消費者組內的消費者則共享該訊息；在佇列模式下，一個訊息只能被一個消費者組內的某個消費者消費。這種靈活性使得Kafka可以適應不同的業務需求和數據處理場景。
- 動態擴充套件 ：隨著業務規模的擴大或縮小，可以動態地增加或減少消費者組的成員。新加入的消費者會自動從已有的副本中拉取數據並開始消費；而離開的消費者會自動感知並停止消費。這種動態的擴充套件性使得 Kafka 能夠隨著業務的發展而靈活地擴充套件處理能力。
消費組和分區的關系： 消費者（數量） <= 分區數 。
5.如何保證高可用？
Partition 備份節點叫做 Follower 節點，負責數據讀寫的節點叫做 Leader 節點。
Kafka 分區類別有以下兩種：
- Leader Partition ：主節點，負責數據寫入和讀取。
- Follower Partition ：副本節點，用於數據備份和主節點宕機之後的分區選舉，保證了 Kafka 服務的高可用。
小結
Kafka 架構最終組成如下：
它們分別是：
- 生產者（Producer） ：負責將訊息發送到 Kafka 集群。
- 消費組（Consumer Group） ：用於實作對一個主題（Topic）中訊息進行並行消費和負載均衡的機制。
- 消費者（Consumer） ：負責從 Kafka 集群中讀取、消費訊息。
- 代理（Broker） ：Kafka 伺服器（Kafka 服務），負責儲存和轉發訊息。
- 主題（Topic） ：訊息的邏輯分類，生產者將訊息發送到特定的主題，消費者從特定的主題訂閱訊息。
- 分區（Partition） ：主題可以被分為多個分區，每個分區是一個有序的、不可變的訊息序列。分區可以分布在不同的 broker 上，實作水平擴充套件。分區分為 Leader 分區，和 Follower 分區。
- Zookeeper ：用於管理 Broker 集群的後設資料，如分區分配、領導者選舉、消費者組和消費者偏移量等資訊等。
本文已收錄到我的面試小站 [www.javacn.site](https://www.javacn.site)，其中包含的內容有：Redis、JVM、並行、並行、MySQL、Spring、Spring MVC、Spring Boot、Spring Cloud、MyBatis、設計模式、訊息佇列等模組。
