這篇文章將帶著大家參透：到底什麼是 Kafka 架構設計的任督二脈？
把握住了這個關鍵點，我相信你將能更好地理解 Kafka 的架構設計，進而順藤摸瓜地掌握 Kafka 的核心技術方案。
1. Kafka 的技術難點究竟在哪？
大家先了解兩個關鍵資訊：
1、Kafka 為實時日誌流而生，要處理的併發和
資料量非常大。
可見，Kafka 本身就是一個高併發系統，它必然會遇到高併發場景下典型的三高挑戰：
高效能、高可用和高擴充套件。
2、為了簡化實現的複雜度，Kafka 最終採用了很巧妙的訊息模型：
它將所有訊息進行了持久化儲存，讓消費者自己各取所需，想取哪個訊息，想什麼時候取都行，只需要傳遞一個訊息的 offset 進行拉取即可。
最終 Kafka 將自己退化成了一個
「儲存系統」
。因此，海量訊息的儲存問題就是 Kafka 架構設計中的最大技術難點。
2. 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 架構設計的來龍去脈，知其所以然。
