[[404881]]

大家好，我是武哥。這是《吃透 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公眾號。