[[404881]]

大家好，我是武哥。這是《吃透 MQ 系列》的第三篇，有關(guān) Kafka 的架構(gòu)設(shè)計。

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

把握住了這個關(guān)鍵點，我相信你將能更好地理解 Kafka 的架構(gòu)設(shè)計，進而順藤摸瓜地掌握 Kafka 的核心技術(shù)方案。

廢話不多說了，開始發(fā)車。

1. Kafka 的技術(shù)難點究竟在哪?

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

1、Kafka 為實時日志流而生，要處理的并發(fā)和數(shù)據(jù)量非常大?？梢姡琄afka 本身就是一個高并發(fā)系統(tǒng)，它必然會遇到高并發(fā)場景下典型的三高挑戰(zhàn)：高性能、高可用和高擴展。

2、為了簡化實現(xiàn)的復(fù)雜度，Kafka 最終采用了很巧妙的消息模型：它將所有消息進行了持久化存儲，讓消費者自己各取所需，想取哪個消息，想什么時候取都行，只需要傳遞一個消息的 offset 進行拉取即可。

最終 Kafka 將自己退化成了一個「存儲系統(tǒng)」。因此，海量消息的存儲問題就是 Kafka 架構(gòu)設(shè)計中的最大技術(shù)難點。

2. Kafka 架構(gòu)設(shè)計的任督二脈

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

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

1、比如數(shù)據(jù)庫設(shè)計中，當(dāng)單表的數(shù)據(jù)量達到幾千萬或者上億時，我們會將它拆分成多個庫或者多張表。

2、比如緩存設(shè)計中，當(dāng)單個 Redis 實例的數(shù)據(jù)量達到幾十個 G 引發(fā)性能瓶頸時，我們會將單機架構(gòu)改成分片集群架構(gòu)。

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

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

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

1、當(dāng)大家聽到京廣高速的時候，知道這是一條從北京到廣州的高速路，這是邏輯上的叫法，可以理解成 Kafka 中的 Topic(主題)。

2、一條高速路通常會有多個車道進行分流，每個車道上的車都是通往一個目的地的(屬于同一個Topic)，這里所說的車道便是 Partition。

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

其中分區(qū)路由可以簡單理解成一個 Hash 函數(shù)，生產(chǎn)者在發(fā)送消息時，完全可以自定義這個函數(shù)來決定分區(qū)規(guī)則。如果分區(qū)規(guī)則設(shè)定合理，所有消息將均勻地分配到不同的分區(qū)中。

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

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

1、Partition 是存儲的關(guān)鍵所在，MQ「一發(fā)一存一消費」的核心流程必然圍繞它展開。

2、Kafka 高并發(fā)設(shè)計中最難的三高問題都能和 Partition 關(guān)聯(lián)起來。

因此，以 Partition 作為根，能很自然地聯(lián)想出 Kafka 架構(gòu)設(shè)計中的各個知識點，形成可靠的知識體系。

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

3. Kafka的宏觀架構(gòu)設(shè)計

接下來，我們再看看 Partition 的分布式能力究竟是如何實現(xiàn)的?它又是怎么和 Kafka 的整體架構(gòu)關(guān)聯(lián)起來的?

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

假設(shè)現(xiàn)在有兩個 Topic，每個 Topic 都設(shè)置了兩個 Partition，如果 Kafka 集群是兩臺機器，部署架構(gòu)將會是下面這樣：

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

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

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

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

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

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

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

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

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

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

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

所以 Kafka 必須具備故障轉(zhuǎn)移能力才行，當(dāng)某臺機器宕機后仍然能保證服務(wù)可用。

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

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

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

現(xiàn)在，我假設(shè) Kafka 集群中有 4 臺服務(wù)器，主題 A 和主題 B 都有兩個 Partition，且每個 Partition 各有兩個副本，那最終的多副本架構(gòu)將如下圖所示：

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

理解了上面這些內(nèi)容，最后我們再反過來看下 Kafka 的整體架構(gòu)：

1、Producer：生產(chǎn)者，負責(zé)創(chuàng)建消息，然后投遞到 Kafka 集群中，投遞時需要指定消息所屬的 Topic，同時確定好發(fā)往哪個 Partition。

2、Consumer：消費者，會根據(jù)它所訂閱的 Topic 以及所屬的消費組，決定從哪些 Partition 中拉取消息。

3、Broker：消息服務(wù)器，可水平擴展，負責(zé)分區(qū)管理、消息的持久化、故障自動轉(zhuǎn)移等。

4、Zookeeper：負責(zé)集群的元數(shù)據(jù)管理等功能，比如集群中有哪些 broker 節(jié)點以及 Topic，每個 Topic 又有哪些 Partition 等。

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

4. 寫在最后

本文以 Partition 為切入點，從宏觀角度解析了 Kafka 的整體架構(gòu)，再簡單總結(jié)下本文的內(nèi)容：

1、Kafka 通過巧妙的模型設(shè)計，將自己退化成一個海量消息的存儲系統(tǒng)。

2、為了解決存儲的擴展性問題，Kafka 對數(shù)據(jù)進行了水平拆分，引出了 Partition(分區(qū))，這是 Kafka 部署的基本單元，同時也是 Kafka 并發(fā)處理的最小粒度。

3、對于一個高并發(fā)系統(tǒng)來說，還需要做到高可用，Kafka 通過 Partition 的多副本冗余機制進行故障轉(zhuǎn)移，確保了高可靠。

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

本文轉(zhuǎn)載自微信公眾號「武哥漫談IT」，可以通過以下二維碼關(guān)注。轉(zhuǎn)載本文請聯(lián)系武哥漫談IT公眾號。