Kafka原理篇：圖解kakfa架構(gòu)原理
這是[碼哥]Kafka 系列文章的第二篇，碼哥將從原理、實踐和源碼角度為大家深入剖析并實踐 Kafka。此系列包括[原理篇]、[實踐篇]和[源碼篇]。這篇是[原理篇]的第二篇，主要講解 Kafka 的架構(gòu)和實現(xiàn)原理。
讀者可以回顧之前的文章《Kafka 性能篇：為何 Kafka 這么"快"？》。
今天我們來深入講解 Kafka 的架構(gòu)和實現(xiàn)原理。[碼哥]將從架構(gòu)和細節(jié)入手，以生動的圖深入講解 Kafka 的實現(xiàn)原理。
我想很多同學(xué)之前可能已經(jīng)看過很多 Kafka 原理相關(guān)的文章，但往往看時"牛逼"聲連連，激情滿滿，總覺得自己又學(xué)習(xí)到了各種“吊炸天”的技術(shù)。但很多同學(xué)往往是不覺明厲，把文章結(jié)合面試題背一背還能應(yīng)付一下半吊子面試官?？梢杂龅嚼纤緳C面試官，或是進入實戰(zhàn)，卻對很多概念和實現(xiàn)摸棱兩可。
所以，[碼哥]決定圖解 Kakfa，卻讓很多半懂不懂的同學(xué)可以加深對 Kafka 實現(xiàn)原理的理解。
同時建議讀者同學(xué)結(jié)合 Kafka 的配置去了解 Kafka 的實現(xiàn)原理，Kafka 有大量的配置，這也是 Kafka 高度擴展的一個表現(xiàn)，很多同學(xué)對 Kafka 的配置也不敢輕易改動。所以理解這些配置背后的實現(xiàn)原理，可以讓我們在實踐中懂得如何使用和優(yōu)化 Kafka。既可面試造火箭，也可以實戰(zhàn)造火箭。
Kafka 配置說明鏈接：https://kafka.apache.org/documentation
下面是本文的主要的內(nèi)容：
由于內(nèi)容太多，怕步子邁太大扯著蛋，[碼哥]決定將文章分成三篇。此文只會涉及上面圖中"橙色"的部分。
從本文你將學(xué)習(xí)到：
Kafka 架構(gòu)設(shè)計哲學(xué)和原理 Kafka 中 zookeeper 的作用 Kafka Controller 實現(xiàn)原理 Kafka Network 原理
開篇寄語
盡可能做一些產(chǎn)品出來，有一個作品很重要，這是別人了解你的窗口。如果可能，給自己開一個公眾號或者一個博客，記錄自己每天的見聞思考。剛開始記會很凌亂沒有邏輯，但堅持下去一定會有很大價值。
Architecture
理解 Kafka 架構(gòu)，就是理解 Kafka 的各種組件的概念，以及這些組件的關(guān)系。先簡單看一下各組件及其簡單說明。
不要去嘗試記憶他們
Producer： 生產(chǎn)者，發(fā)送消息的一方。生產(chǎn)者負責(zé)創(chuàng)建消息，然后將其發(fā)送到 Kafka。
Consumer： 消費者，接受消息的一方。消費者連接到 Kafka 上并接收消息，進而進行相應(yīng)的業(yè)務(wù)邏輯處理。
Consumer Group： 一個消費者組可以包含一個或多個消費者。使用多分區(qū) + 多消費者方式可以極大提高數(shù)據(jù)下游的處理速度，同一消費組中的消費者不會重復(fù)消費消息，同樣的，不同消費組中的消費者消息消息時互不影響。Kafka 就是通過消費組的方式來實現(xiàn)消息 P2P 模式和廣播模式。
Broker： 服務(wù)代理節(jié)點。Broker 是 Kafka 的服務(wù)節(jié)點，即 Kafka 的服務(wù)器。
Topic： Kafka 中的消息以 Topic 為單位進行劃分，生產(chǎn)者將消息發(fā)送到特定的 Topic，而消費者負責(zé)訂閱 Topic 的消息并進行消費。
Partition： Topic 是一個邏輯的概念，它可以細分為多個分區(qū)，每個分區(qū)只屬于單個主題。同一個主題下不同分區(qū)包含的消息是不同的，分區(qū)在存儲層面可以看作一個可追加的日志（Log）文件，消息在被追加到分區(qū)日志文件的時候都會分配一個特定的偏移量（offset）。
Offset： offset 是消息在分區(qū)中的唯一標識，Kafka 通過它來保證消息在分區(qū)內(nèi)的順序性，不過 offset 并不跨越分區(qū)，也就是說，Kafka 保證的是分區(qū)有序性而不是主題有序性。
Replication： 副本，是 Kafka 保證數(shù)據(jù)高可用的方式，Kafka 同一 Partition 的數(shù)據(jù)可以在多 Broker 上存在多個副本，通常只有主副本對外提供讀寫服務(wù)，當(dāng)主副本所在 broker 崩潰或發(fā)生網(wǎng)絡(luò)異常，Kafka 會在 Controller 的管理下會重新選擇新的 Leader 副本對外提供讀寫服務(wù)。
Record： 實際寫入 Kafka 中并可以被讀取的消息記錄。每個 record 包含了 key、value 和 timestamp。
我們理解了也就自然記住了
我們應(yīng)該通過理解的方式去記憶它們。
生產(chǎn)者-消費者
生產(chǎn)者-消費者是一種設(shè)計模式，生產(chǎn)者和消費者之間通過添加一個中間組件來達到解耦。生產(chǎn)者向中間組件生成數(shù)據(jù)，消費者消費數(shù)據(jù)。
就像 65 哥讀書時給小芳寫情書，這里 65 哥就是生產(chǎn)者，情書就是消息，小芳就是消費者。但有時候小芳不在，或者比較忙，65 哥也比較害羞，不敢直接將情書塞小芳手里，于是將情書塞在小芳抽屜中。所以抽屜就是這個中間組件。
在程序中我們通常使用Queue來作為這個中間組件?？梢允褂枚嗑€程向隊列中寫入數(shù)據(jù)，另外的消費者線程依次讀取隊列中的數(shù)據(jù)進行消費。模型如下圖所示：
生產(chǎn)者-消費者模式通過添加一個中間層，不僅可以解耦生產(chǎn)者和消費者，使其易于擴展，還可以異步化調(diào)用、緩沖消息等。
分布式隊列
后來 65 哥和小芳異地了，65 哥在卷都奮斗，小芳在魔都逛街。于是只能通過郵局寄曖昧信了。這樣 65 哥、郵局和小芳就成了分布式的了。65 哥將信件發(fā)給郵局，小芳從郵局拿到 65 哥寫的信，再回去慢慢看。
Kafka 的消息生產(chǎn)者就是Producer，上游消費者進程添加 Kafka Client 創(chuàng)建 Kafka Producer，向 Broker 發(fā)送消息，Broker 是集群部署在遠程服務(wù)器上的 Kafka Server 進程，下游消費者進程引入 Kafka Consumer API 持續(xù)消費隊列中消息。
因為 Kafka Consumer 使用 Poll 的模式，需要 Consumer 主動拉去消息。所有小芳只能定期去郵局拿信件了(呃，果然主動權(quán)都在小芳手上啊)。
主題
郵局不能只為 65 哥服務(wù)，雖然 65 哥一天寫好幾封信。但也無法挽回郵局的損失。所以郵局是可以供任何人寄信。只需要寄信人寫好地址(主題)，郵局建有兩地的通道就可以發(fā)收信件了。
Kafka 的 Topic 才相當(dāng)于一個隊列，Broker 是所有隊列部署的機器?？梢园礃I(yè)務(wù)創(chuàng)建不同的 Topic，Producer 向所屬業(yè)務(wù)的 Topic 發(fā)送消息，相應(yīng)的 Consumer 可以消費并處理消息。
分區(qū)
由于 65 哥寫的信太多，一個郵局已經(jīng)無法滿足 65 哥的需求，郵政公司只能多建幾個郵局了，65 哥將信件按私密度分類(分區(qū)策略)，從不同的郵局寄送。
同一個 Topic 可以創(chuàng)建多個分區(qū)。理論上分區(qū)越多并發(fā)度越高，Kafka 會根據(jù)分區(qū)策略將分區(qū)盡可能均衡的分布在不同的 Broker 節(jié)點上，以避免消息傾斜，不同的 Broker 負載差異太大。分區(qū)也不是越多越好哦，畢竟太多郵政公司也管理不過來。具體的原因可以參考[碼哥]之前的文章《Kafka 性能篇：為何 Kafka 這么"快"？》
副本
為防止由于郵局的問題，比如交通斷啦，郵車沒油啦。導(dǎo)致 65 哥的曖昧信無法寄到小芳手上，使得 65 哥晚上遠程跪鍵盤。郵局決定將 65 哥的信件復(fù)制幾份發(fā)到多個正常的郵局，這樣只要有一個郵局還在，小芳就可以收到 65 哥的信了。
Kafka 采用分區(qū)副本的方式來保證數(shù)據(jù)的高可用，每個分區(qū)都將建立指定數(shù)量的副本數(shù)，kakfa 保證同一分區(qū)副本盡量分布在不同的 Broker 節(jié)點上，以防止 Broker 宕機導(dǎo)致所有副本不可用。Kafka 會為分區(qū)的多個副本選舉一個作為主副本(Leader)，主副本對外提供讀寫服務(wù)，從副本(Follower)實時同步 Leader 的數(shù)據(jù)。
多消費者
哎，65 哥的信件滿天飛，小芳天天跑郵局，還要一一拆開看，65 哥寫的信又臭又長，讓小芳忙得滿身大漢大汗。于是小芳啪的一下，很快啊，變出多個分身去不同的郵局取信，這樣小芳終于可以擠出額外的時間逛街了。
廣播消息
郵局最近提供了定制明信片業(yè)務(wù)，每個人都可以設(shè)計明信片，同一個身份只能領(lǐng)取一種明信片。65 哥設(shè)計了一堆，廣播給所有漂亮的小妹妹都可以來領(lǐng)取，美女啪變出的分身也可以來領(lǐng)取，但是同一個身份的多個分身只能取一種明信片。
Kafka 通過 Consumer Group 來實現(xiàn)廣播模式消息訂閱，即不同 group 下的 consumer 可以重復(fù)消費消息，相互不影響，同一個 group 下的 consumer 構(gòu)成一個整體。
最后我們完成了 Kafka 的整體架構(gòu)，如下：
Zookeeper
Zookeeper 是一個成熟的分布式協(xié)調(diào)服務(wù)，它可以為分布式服務(wù)提供分布式配置服、同步服務(wù)和命名注冊等能力.。對于任何分布式系統(tǒng)，都需要一種協(xié)調(diào)任務(wù)的方法。Kafka 是使用 ZooKeeper 而構(gòu)建的分布式系統(tǒng)。但是也有一些其他技術(shù)（例如 Elasticsearch 和 MongoDB）具有其自己的內(nèi)置任務(wù)協(xié)調(diào)機制。
Kafka 將 Broker、Topic 和 Partition 的元數(shù)據(jù)信息存儲在 Zookeeper 上。通過在 Zookeeper 上建立相應(yīng)的數(shù)據(jù)節(jié)點，并監(jiān)聽節(jié)點的變化，Kafka 使用 Zookeeper 完成以下功能：
Kafka Controller 的 Leader 選舉 Kafka 集群成員管理 Topic 配置管理 分區(qū)副本管理
我們看一看 Zookeeper 下 Kafka 創(chuàng)建的節(jié)點，即可一目了然的看出這些相關(guān)的功能。
Controller
Controller 是從 Broker 中選舉出來的，負責(zé)分區(qū) Leader 和 Follower 的管理。當(dāng)某個分區(qū)的 leader 副本發(fā)生故障時，由 Controller 負責(zé)為該分區(qū)選舉新的 leader 副本。當(dāng)檢測到某個分區(qū)的 ISR(In-Sync Replica)集合發(fā)生變化時，由控制器負責(zé)通知所有 broker 更新其元數(shù)據(jù)信息。當(dāng)使用kafka-topics.sh腳本為某個 topic 增加分區(qū)數(shù)量時，同樣還是由控制器負責(zé)分區(qū)的重新分配。
Kafka 中 Contorller 的選舉的工作依賴于 Zookeeper，成功競選為控制器的 broker 會在 Zookeeper 中創(chuàng)建/controller這個臨時（EPHEMERAL）節(jié)點。
選舉過程
Broker 啟動的時候嘗試去讀取/controller節(jié)點的brokerid的值，如果brokerid的值不等于-1，則表明已經(jīng)有其他的 Broker 成功成為 Controller 節(jié)點，當(dāng)前 Broker 主動放棄競選；如果不存在/controller節(jié)點，或者 brokerid 數(shù)值異常，當(dāng)前 Broker 嘗試去創(chuàng)建/controller這個節(jié)點，此時也有可能其他 broker 同時去嘗試創(chuàng)建這個節(jié)點，只有創(chuàng)建成功的那個 broker 才會成為控制器，而創(chuàng)建失敗的 broker 則表示競選失敗。每個 broker 都會在內(nèi)存中保存當(dāng)前控制器的 brokerid 值，這個值可以標識為 activeControllerId。
實現(xiàn)
Controller 讀取 Zookeeper 中的節(jié)點數(shù)據(jù)，初始化上下文(Controller Context)，并管理節(jié)點變化，變更上下文，同時也需要將這些變更信息同步到其他普通的 broker 節(jié)點中。Controller 通過定時任務(wù)，或者監(jiān)聽器模式獲取 zookeeper 信息，事件監(jiān)聽會更新更新上下文信息，如圖所示，Controller 內(nèi)部也采用生產(chǎn)者-消費者實現(xiàn)模式，Controller 將 zookeeper 的變動通過事件的方式發(fā)送給事件隊列，隊列就是一個LinkedBlockingQueue，事件消費者線程組通過消費消費事件，將相應(yīng)的事件同步到各 Broker 節(jié)點。這種隊列 FIFO 的模式保證了消息的有序性。
職責(zé)
Controller 被選舉出來，作為整個 Broker 集群的管理者，管理所有的集群信息和元數(shù)據(jù)信息。它的職責(zé)包括下面幾部分：
處理 Broker 節(jié)點的上線和下線，包括自然下線、宕機和網(wǎng)絡(luò)不可達導(dǎo)致的集群變動，Controller 需要及時更新集群元數(shù)據(jù)，并將集群變化通知到所有的 Broker 集群節(jié)點； 創(chuàng)建 Topic 或者 Topic 擴容分區(qū)，Controller 需要負責(zé)分區(qū)副本的分配工作，并主導(dǎo) Topic 分區(qū)副本的 Leader 選舉。 管理集群中所有的副本和分區(qū)的狀態(tài)機，監(jiān)聽狀態(tài)機變化事件，并作出相應(yīng)的處理。Kafka 分區(qū)和副本數(shù)據(jù)采用狀態(tài)機的方式管理，分區(qū)和副本的變化都在狀態(tài)機內(nèi)會引起狀態(tài)機狀態(tài)的變更，從而觸發(fā)相應(yīng)的變化事件。
“65 哥：狀態(tài)機啊，聽起來好復(fù)雜。
”
Controller 管理著集群中所有副本和分區(qū)的狀態(tài)機。大家不要被狀態(tài)機這個詞唬住了。理解狀態(tài)機很簡單。先理解模型，即這是什么關(guān)于什么模型，然后就是模型的狀態(tài)有哪些，模型狀態(tài)之間如何轉(zhuǎn)換，轉(zhuǎn)換時發(fā)送相應(yīng)的變化事件。
Kafka 的分區(qū)和副本狀態(tài)機很簡單。我們先理解，這分別是管理 Kafka Topic 的分區(qū)和副本的。它們的狀態(tài)也很簡單，就是 CRUD，具體說來如下：
分區(qū)狀態(tài)機
PartitionStateChange，管理 Topic 的分區(qū)，它有以下 4 種狀態(tài)：
NonExistentPartition：該狀態(tài)表示分區(qū)沒有被創(chuàng)建過或創(chuàng)建后被刪除了。 NewPartition：分區(qū)剛創(chuàng)建后，處于這個狀態(tài)。此狀態(tài)下分區(qū)已經(jīng)分配了副本，但是還沒有選舉 leader，也沒有 ISR 列表。 OnlinePartition：一旦這個分區(qū)的 leader 被選舉出來，將處于這個狀態(tài)。 OfflinePartition：當(dāng)分區(qū)的 leader 宕機，轉(zhuǎn)移到這個狀態(tài)。
我們用一張圖來直觀的看看這些狀態(tài)是如何變化的，以及在狀態(tài)發(fā)生變化時 Controller 都有哪些操作：
副本狀態(tài)機
ReplicaStateChange，副本狀態(tài)，管理分區(qū)副本信息，它也有 4 種狀態(tài)：
NewReplica: 創(chuàng)建 topic 和分區(qū)分配后創(chuàng)建 replicas，此時，replica 只能獲取到成為 follower 狀態(tài)變化請求。 OnlineReplica: 當(dāng) replica 成為 parition 的 assingned replicas 時，其狀態(tài)變?yōu)?OnlineReplica, 即一個有效的 OnlineReplica。 OfflineReplica: 當(dāng)一個 replica 下線，進入此狀態(tài)，這一般發(fā)生在 broker 宕機的情況下； NonExistentReplica: Replica 成功刪除后，replica 進入 NonExistentReplica 狀態(tài)。
副本狀態(tài)間的變化如下圖所示，Controller 在狀態(tài)變化時會做出相應(yīng)的操作：
Network
Kafka 的網(wǎng)絡(luò)通信模型是基于 NIO 的 Reactor 多線程模型來設(shè)計的。其中包含了一個Acceptor線程，用于處理新的連接，Acceptor 有 N 個 Processor 線程 select 和 read socket 請求，N 個 Handler 線程處理請求并相應(yīng)，即處理業(yè)務(wù)邏輯。下面就是 KafkaServer 的模型圖：
之后的 Kafka 源碼篇，[碼哥]將從源碼的角度來講解這些原理在代碼上的具體實現(xiàn)，各位敬請期待啊。
推薦閱讀：
歡迎關(guān)注微信公眾號：互聯(lián)網(wǎng)全棧架構(gòu)，收取更多有價值的信息。