[[394499]]

大家好，我是武哥。這是《吃透 MQ 系列》的第三篇，有關 Kafka 的架構設計。

這篇文章將帶著大家參透：到底什么是 Kafka 架構設計的任督二脈?

把握住了這個關鍵點，我相信你將能更好地理解 Kafka 的架構設計，進而順藤摸瓜地掌握 Kafka 的核心技術方案。

廢話不多說了，開始發車。

1. Kafka 的技術難點究竟在哪?

前一篇文章《扒開 Kafka 的神秘面紗》 交代了兩個關鍵信息：

• 1、Kafka 為實時日志流而生，要處理的并發和數據量非常大?？梢?，Kafka 本身就是一個高并發系統，它必然會遇到高并發場景下典型的三高挑戰：高性能、高可用和高擴展。
• 2、為了簡化實現的復雜度，Kafka 最終采用了很巧妙的消息模型：它將所有消息進行了持久化存儲，讓消費者自己各取所需，想取哪個消息，想什么時候取都行，只需要傳遞一個消息的 offset 進行拉取即可。

最終 Kafka 將自己退化成了一個「存儲系統」。因此，海量消息的存儲問題就是 Kafka 架構設計中的最大技術難點。

2. Kafka 架構設計的任督二脈

下面我們再接著分析下：Kafka 究竟是如何解決存儲問題的?

面對海量數據，單機的存儲容量和讀寫性能肯定有限，大家很容易想到一種存儲方案：對數據進行分片存儲。這種方案在我們實際工作中也非常常見：

• 1、比如數據庫設計中，當單表的數據量達到幾千萬或者上億時，我們會將它拆分成多個庫或者多張表。
• 2、比如緩存設計中，當單個 Redis 實例的數據量達到幾十個 G 引發性能瓶頸時，我們會將單機架構改成分片集群架構。

類似的拆分思想在 HDFS、ElasticSearch 等中間件中都能看到。

Kafka 也不例外，它同樣采用了這種水平拆分方案。在 Kafka 的術語中，拆分后的數據子集叫做 Partition(分區)，各個分區的數據合集即全量數據。

我們再來看下 Kafka 中的 Partition 具體是如何工作的?舉一個很形象的例子，如果我們把「Kafka」類比成「高速公路」：

• 1、當大家聽到京廣高速的時候，知道這是一條從北京到廣州的高速路，這是邏輯上的叫法，可以理解成 Kafka 中的 Topic(主題)。
• 2、一條高速路通常會有多個車道進行分流，每個車道上的車都是通往一個目的地的(屬于同一個Topic)，這里所說的車道便是 Partition。

這樣，一條消息的流轉路徑就如下圖所示，先走主題路由，然后走分區路由，最終決定這條消息該發往哪個分區。

其中分區路由可以簡單理解成一個 Hash 函數，生產者在發送消息時，完全可以自定義這個函數來決定分區規則。如果分區規則設定合理，所有消息將均勻地分配到不同的分區中。

通過這樣兩層關系，最終在 Topic 之下，就有了一個新的劃分單位：Partition。先通過 Topic 對消息進行邏輯分類，然后通過 Partition 進一步做物理分片，最終多個 Partition 又會均勻地分布在集群中的每臺機器上，從而很好地解決了存儲的擴展性問題。

因此，Partition 是 Kafka 最基本的部署單元。本文之所以將 Partition 稱作 Kafka 架構設計的任督二脈，基于下面兩點原因：

• 1、Partition 是存儲的關鍵所在，MQ「一發一存一消費」的核心流程必然圍繞它展開。
• 2、Kafka 高并發設計中最難的三高問題都能和 Partition 關聯起來。

因此，以 Partition 作為根，能很自然地聯想出 Kafka 架構設計中的各個知識點，形成可靠的知識體系。

下面，請大家繼續跟著我的思路，以 Partition 為線索，對 Kafka 的宏觀架構進行解析。

3. Kafka的宏觀架構設計

接下來，我們再看看 Partition 的分布式能力究竟是如何實現的?它又是怎么和 Kafka 的整體架構關聯起來的?

前面講過 Partition 是 Topic 之下的一個劃分單位，它是 Kafka 最基本的部署單元，它將決定 Kafka 集群的組織方式。

假設現在有兩個 Topic，每個 Topic 都設置了兩個 Partition，如果 Kafka 集群是兩臺機器，部署架構將會是下面這樣：

可以看到：同一個 Topic 的兩個 Partition 分布在不同的消息服務器上，能做到消息的分布式存儲了。但是對于 Kafka 這個高并發系統來說，僅存儲可擴展還不夠，消息的拉取也必須并行才行，否則會遇到極大的性能瓶頸。

那我們再看看消費端，它又是如何跟 Partition 結合并做到并行處理的?

從消費者來看，首先要滿足兩個基本訴求：

1、廣播消費能力：同一個 Topic 可以被多個消費者訂閱，一條消息能夠被消費多次。

2、集群消費能力：當消費者本身也是集群時，每一條消息只能分發給集群中的一個消費者進行處理。

為了滿足這兩點要求，Kafka 引出了消費組的概念，每個消費者都有一個對應的消費組，組間進行廣播消費，組內進行集群消費。此外，Kafka 還限定了：每個 Partition 只能由消費組中的一個消費者進行消費。

最終的消費關系如下圖所示：假設主題 A 共有 4 個分區，消費組 2 只有兩個消費者，最終這兩個消費組將平分整個負載，各自消費兩個分區的消息。

如果要加快消息的處理速度，該如何做呢?也很簡單，向消費組 2 中增加新的消費者即可，Kafka 將以 Partition 為單位重新做負載均衡。當增加到 4 個消費者時，每個消費者僅需處理 1 個 Partition，處理速度將提升兩倍。

到這里，存儲可擴展、消息并行處理這兩個難題都解決了。但是高并發架構設計上，還遺留了一個很重要的問題：那就是高可用設計。

在 Kafka 集群中，每臺機器都存儲了一些 Partition，一旦某臺機器宕機，上面的數據不就丟失了嗎?

此時，你一定會想到對消息進行持久化存儲，但是持久化只能解決一部分問題，它只能確保機器重啟后，歷史數據不丟失。但在機器恢復之前，這部分數據將一直無法訪問。這對于高并發系統來說，是無法忍受的。

所以 Kafka 必須具備故障轉移能力才行，當某臺機器宕機后仍然能保證服務可用。

如果大家去分析任何一個高可靠的分布式系統，比如 ElasticSearch、Redis Cluster，其實它們都有一套多副本的冗余機制。

沒錯，Kafka 正是通過 Partition 的多副本機制解決了高可用問題。在 Kafka 集群中，每個 Partition 都有多個副本，同一分區的不同副本中保存的是相同的消息。

副本之間是 “一主多從” 的關系，其中 leader 副本負責讀寫請求，follower 副本只負責和 leader 副本同步消息，當 leader 副本發生故障時，它才有機會被選舉成新的 leader 副本并對外提供服務，否則一直是待命狀態。

現在，我假設 Kafka 集群中有 4 臺服務器，主題 A 和主題 B 都有兩個 Partition，且每個 Partition 各有兩個副本，那最終的多副本架構將如下圖所示：

很顯然，這個集群中任何一臺機器宕機，都不會影響 Kafka 的可用性，數據仍然是完整的。

理解了上面這些內容，最后我們再反過來看下 Kafka 的整體架構：

• 1、Producer：生產者，負責創建消息，然后投遞到 Kafka 集群中，投遞時需要指定消息所屬的 Topic，同時確定好發往哪個 Partition。
• 2、Consumer：消費者，會根據它所訂閱的 Topic 以及所屬的消費組，決定從哪些 Partition 中拉取消息。
• 3、Broker：消息服務器，可水平擴展，負責分區管理、消息的持久化、故障自動轉移等。
• 4、Zookeeper：負責集群的元數據管理等功能，比如集群中有哪些 broker 節點以及 Topic，每個 Topic 又有哪些 Partition 等。

很顯然，在 Kafka 整體架構中，Partition 是發送消息、存儲消息、消費消息的紐帶。吃透了它，再去理解整體架構，脈絡會更加清晰。

4. 寫在最后

本文以 Partition 為切入點，從宏觀角度解析了 Kafka 的整體架構，再簡單總結下本文的內容：

• 1、Kafka 通過巧妙的模型設計，將自己退化成一個海量消息的存儲系統。
• 2、為了解決存儲的擴展性問題，Kafka 對數據進行了水平拆分，引出了 Partition(分區)，這是 Kafka 部署的基本單元，同時也是 Kafka 并發處理的最小粒度。
• 3、對于一個高并發系統來說，還需要做到高可用，Kafka 通過 Partition 的多副本冗余機制進行故障轉移，確保了高可靠。

希望這篇文章能讓大家擺脫死記硬背的模式，先找到一個支點，再去推敲 Kafka 架構設計的來龍去脈，知其所以然。

本文轉載自微信公眾號「武哥漫談IT」，可以通過以下二維碼關注。轉載本文請聯系武哥漫談IT公眾號。