讀者可以回顧之前的文章《Kafka 性能篇：為何 Kafka 這么"快"？》。

今天我們來(lái)深入講解 Kafka 的架構(gòu)和實(shí)現(xiàn)原理。[碼哥]將從架構(gòu)和細(xì)節(jié)入手，以生動(dòng)的圖深入講解 Kafka 的實(shí)現(xiàn)原理。

我想很多同學(xué)之前可能已經(jīng)看過(guò)很多 Kafka 原理相關(guān)的文章，但往往看時(shí)"牛逼"聲連連，激情滿滿，總覺(jué)得自己又學(xué)習(xí)到了各種“吊炸天”的技術(shù)。但很多同學(xué)往往是不覺(jué)明厲，把文章結(jié)合面試題背一背還能應(yīng)付一下半吊子面試官?？梢杂龅嚼纤緳C(jī)面試官，或是進(jìn)入實(shí)戰(zhàn)，卻對(duì)很多概念和實(shí)現(xiàn)摸棱兩可。

所以，[碼哥]決定圖解 Kakfa，卻讓很多半懂不懂的同學(xué)可以加深對(duì) Kafka 實(shí)現(xiàn)原理的理解。

同時(shí)建議讀者同學(xué)結(jié)合 Kafka 的配置去了解 Kafka 的實(shí)現(xiàn)原理，Kafka 有大量的配置，這也是 Kafka 高度擴(kuò)展的一個(gè)表現(xiàn)，很多同學(xué)對(duì) Kafka 的配置也不敢輕易改動(dòng)。所以理解這些配置背后的實(shí)現(xiàn)原理，可以讓我們?cè)趯?shí)踐中懂得如何使用和優(yōu)化 Kafka。既可面試造火箭，也可以實(shí)戰(zhàn)造火箭。

Kafka 配置說(shuō)明鏈接：https://kafka.apache.org/documentation

下面是本文的主要的內(nèi)容：

由于內(nèi)容太多，怕步子邁太大扯著蛋，[碼哥]決定將文章分成三篇。此文只會(huì)涉及上面圖中"橙色"的部分。

從本文你將學(xué)習(xí)到：

• Kafka 架構(gòu)設(shè)計(jì)哲學(xué)和原理
• Kafka 中 zookeeper 的作用
• Kafka Controller 實(shí)現(xiàn)原理
• Kafka Network 原理

開(kāi)篇寄語(yǔ)

盡可能做一些產(chǎn)品出來(lái)，有一個(gè)作品很重要，這是別人了解你的窗口。如果可能，給自己開(kāi)一個(gè)公眾號(hào)或者一個(gè)博客，記錄自己每天的見(jiàn)聞思考。剛開(kāi)始記會(huì)很凌亂沒(méi)有邏輯，但堅(jiān)持下去一定會(huì)有很大價(jià)值。

Architecture

理解 Kafka 架構(gòu)，就是理解 Kafka 的各種組件的概念，以及這些組件的關(guān)系。先簡(jiǎn)單看一下各組件及其簡(jiǎn)單說(shuō)明。

不要去嘗試記憶他們

Producer： 生產(chǎn)者，發(fā)送消息的一方。生產(chǎn)者負(fù)責(zé)創(chuàng)建消息，然后將其發(fā)送到 Kafka。
Consumer： 消費(fèi)者，接受消息的一方。消費(fèi)者連接到 Kafka 上并接收消息，進(jìn)而進(jìn)行相應(yīng)的業(yè)務(wù)邏輯處理。
Consumer Group： 一個(gè)消費(fèi)者組可以包含一個(gè)或多個(gè)消費(fèi)者。使用多分區(qū) + 多消費(fèi)者方式可以極大提高數(shù)據(jù)下游的處理速度，同一消費(fèi)組中的消費(fèi)者不會(huì)重復(fù)消費(fèi)消息，同樣的，不同消費(fèi)組中的消費(fèi)者消息消息時(shí)互不影響。Kafka 就是通過(guò)消費(fèi)組的方式來(lái)實(shí)現(xiàn)消息 P2P 模式和廣播模式。
Broker： 服務(wù)代理節(jié)點(diǎn)。Broker 是 Kafka 的服務(wù)節(jié)點(diǎn)，即 Kafka 的服務(wù)器。
Topic： Kafka 中的消息以 Topic 為單位進(jìn)行劃分，生產(chǎn)者將消息發(fā)送到特定的 Topic，而消費(fèi)者負(fù)責(zé)訂閱 Topic 的消息并進(jìn)行消費(fèi)。
Partition： Topic 是一個(gè)邏輯的概念，它可以細(xì)分為多個(gè)分區(qū)，每個(gè)分區(qū)只屬于單個(gè)主題。同一個(gè)主題下不同分區(qū)包含的消息是不同的，分區(qū)在存儲(chǔ)層面可以看作一個(gè)可追加的日志（Log）文件，消息在被追加到分區(qū)日志文件的時(shí)候都會(huì)分配一個(gè)特定的偏移量（offset）。
Offset： offset 是消息在分區(qū)中的唯一標(biāo)識(shí)，Kafka 通過(guò)它來(lái)保證消息在分區(qū)內(nèi)的順序性，不過(guò) offset 并不跨越分區(qū)，也就是說(shuō)，Kafka 保證的是分區(qū)有序性而不是主題有序性。
Replication： 副本，是 Kafka 保證數(shù)據(jù)高可用的方式，Kafka 同一 Partition 的數(shù)據(jù)可以在多 Broker 上存在多個(gè)副本，通常只有主副本對(duì)外提供讀寫(xiě)服務(wù)，當(dāng)主副本所在 broker 崩潰或發(fā)生網(wǎng)絡(luò)異常，Kafka 會(huì)在 Controller 的管理下會(huì)重新選擇新的 Leader 副本對(duì)外提供讀寫(xiě)服務(wù)。
Record： 實(shí)際寫(xiě)入 Kafka 中并可以被讀取的消息記錄。每個(gè) record 包含了 key、value 和 timestamp。

我們理解了也就自然記住了

我們應(yīng)該通過(guò)理解的方式去記憶它們。

生產(chǎn)者-消費(fèi)者

生產(chǎn)者-消費(fèi)者是一種設(shè)計(jì)模式，生產(chǎn)者和消費(fèi)者之間通過(guò)添加一個(gè)中間組件來(lái)達(dá)到解耦。生產(chǎn)者向中間組件生成數(shù)據(jù)，消費(fèi)者消費(fèi)數(shù)據(jù)。

就像 65 哥讀書(shū)時(shí)給小芳寫(xiě)情書(shū)，這里 65 哥就是生產(chǎn)者，情書(shū)就是消息，小芳就是消費(fèi)者。但有時(shí)候小芳不在，或者比較忙，65 哥也比較害羞，不敢直接將情書(shū)塞小芳手里，于是將情書(shū)塞在小芳抽屜中。所以抽屜就是這個(gè)中間組件。

在程序中我們通常使用Queue來(lái)作為這個(gè)中間組件。可以使用多線程向隊(duì)列中寫(xiě)入數(shù)據(jù)，另外的消費(fèi)者線程依次讀取隊(duì)列中的數(shù)據(jù)進(jìn)行消費(fèi)。模型如下圖所示：

生產(chǎn)者-消費(fèi)者模式通過(guò)添加一個(gè)中間層，不僅可以解耦生產(chǎn)者和消費(fèi)者，使其易于擴(kuò)展，還可以異步化調(diào)用、緩沖消息等。

分布式隊(duì)列

后來(lái) 65 哥和小芳異地了，65 哥在卷都奮斗，小芳在魔都逛街。于是只能通過(guò)郵局寄曖昧信了。這樣 65 哥、郵局和小芳就成了分布式的了。65 哥將信件發(fā)給郵局，小芳從郵局拿到 65 哥寫(xiě)的信，再回去慢慢看。

Kafka 的消息生產(chǎn)者就是Producer，上游消費(fèi)者進(jìn)程添加 Kafka Client 創(chuàng)建 Kafka Producer，向 Broker 發(fā)送消息，Broker 是集群部署在遠(yuǎn)程服務(wù)器上的 Kafka Server 進(jìn)程，下游消費(fèi)者進(jìn)程引入 Kafka Consumer API 持續(xù)消費(fèi)隊(duì)列中消息。

因?yàn)?Kafka Consumer 使用 Poll 的模式，需要 Consumer 主動(dòng)拉去消息。所有小芳只能定期去郵局拿信件了(呃，果然主動(dòng)權(quán)都在小芳手上啊)。

主題

郵局不能只為 65 哥服務(wù)，雖然 65 哥一天寫(xiě)好幾封信。但也無(wú)法挽回郵局的損失。所以郵局是可以供任何人寄信。只需要寄信人寫(xiě)好地址(主題)，郵局建有兩地的通道就可以發(fā)收信件了。

Kafka 的 Topic 才相當(dāng)于一個(gè)隊(duì)列，Broker 是所有隊(duì)列部署的機(jī)器?？梢园礃I(yè)務(wù)創(chuàng)建不同的 Topic，Producer 向所屬業(yè)務(wù)的 Topic 發(fā)送消息，相應(yīng)的 Consumer 可以消費(fèi)并處理消息。

分區(qū)

由于 65 哥寫(xiě)的信太多，一個(gè)郵局已經(jīng)無(wú)法滿足 65 哥的需求，郵政公司只能多建幾個(gè)郵局了，65 哥將信件按私密度分類(分區(qū)策略)，從不同的郵局寄送。

同一個(gè) Topic 可以創(chuàng)建多個(gè)分區(qū)。理論上分區(qū)越多并發(fā)度越高，Kafka 會(huì)根據(jù)分區(qū)策略將分區(qū)盡可能均衡的分布在不同的 Broker 節(jié)點(diǎn)上，以避免消息傾斜，不同的 Broker 負(fù)載差異太大。分區(qū)也不是越多越好哦，畢竟太多郵政公司也管理不過(guò)來(lái)。具體的原因可以參考[碼哥]之前的文章《Kafka 性能篇：為何 Kafka 這么"快"？》

副本

為防止由于郵局的問(wèn)題，比如交通斷啦，郵車沒(méi)油啦。導(dǎo)致 65 哥的曖昧信無(wú)法寄到小芳手上，使得 65 哥晚上遠(yuǎn)程跪鍵盤(pán)。郵局決定將 65 哥的信件復(fù)制幾份發(fā)到多個(gè)正常的郵局，這樣只要有一個(gè)郵局還在，小芳就可以收到 65 哥的信了。

Kafka 采用分區(qū)副本的方式來(lái)保證數(shù)據(jù)的高可用，每個(gè)分區(qū)都將建立指定數(shù)量的副本數(shù)，kakfa 保證同一分區(qū)副本盡量分布在不同的 Broker 節(jié)點(diǎn)上，以防止 Broker 宕機(jī)導(dǎo)致所有副本不可用。Kafka 會(huì)為分區(qū)的多個(gè)副本選舉一個(gè)作為主副本(Leader)，主副本對(duì)外提供讀寫(xiě)服務(wù)，從副本(Follower)實(shí)時(shí)同步 Leader 的數(shù)據(jù)。

多消費(fèi)者

哎，65 哥的信件滿天飛，小芳天天跑郵局，還要一一拆開(kāi)看，65 哥寫(xiě)的信又臭又長(zhǎng)，讓小芳忙得滿身大漢大汗。于是小芳啪的一下，很快啊，變出多個(gè)分身去不同的郵局取信，這樣小芳終于可以擠出額外的時(shí)間逛街了。

廣播消息

郵局最近提供了定制明信片業(yè)務(wù)，每個(gè)人都可以設(shè)計(jì)明信片，同一個(gè)身份只能領(lǐng)取一種明信片。65 哥設(shè)計(jì)了一堆，廣播給所有漂亮的小妹妹都可以來(lái)領(lǐng)取，美女啪變出的分身也可以來(lái)領(lǐng)取，但是同一個(gè)身份的多個(gè)分身只能取一種明信片。

Kafka 通過(guò) Consumer Group 來(lái)實(shí)現(xiàn)廣播模式消息訂閱，即不同 group 下的 consumer 可以重復(fù)消費(fèi)消息，相互不影響，同一個(gè) group 下的 consumer 構(gòu)成一個(gè)整體。

最后我們完成了 Kafka 的整體架構(gòu)，如下：

Zookeeper

Zookeeper 是一個(gè)成熟的分布式協(xié)調(diào)服務(wù)，它可以為分布式服務(wù)提供分布式配置服、同步服務(wù)和命名注冊(cè)等能力.。對(duì)于任何分布式系統(tǒng)，都需要一種協(xié)調(diào)任務(wù)的方法。Kafka 是使用 ZooKeeper 而構(gòu)建的分布式系統(tǒng)。但是也有一些其他技術(shù)（例如 Elasticsearch 和 MongoDB）具有其自己的內(nèi)置任務(wù)協(xié)調(diào)機(jī)制。

Kafka 將 Broker、Topic 和 Partition 的元數(shù)據(jù)信息存儲(chǔ)在 Zookeeper 上。通過(guò)在 Zookeeper 上建立相應(yīng)的數(shù)據(jù)節(jié)點(diǎn)，并監(jiān)聽(tīng)節(jié)點(diǎn)的變化，Kafka 使用 Zookeeper 完成以下功能：

• Kafka Controller 的 Leader 選舉
• Kafka 集群成員管理
• Topic 配置管理
• 分區(qū)副本管理

我們看一看 Zookeeper 下 Kafka 創(chuàng)建的節(jié)點(diǎn)，即可一目了然的看出這些相關(guān)的功能。

Controller

Controller 是從 Broker 中選舉出來(lái)的，負(fù)責(zé)分區(qū) Leader 和 Follower 的管理。當(dāng)某個(gè)分區(qū)的 leader 副本發(fā)生故障時(shí)，由 Controller 負(fù)責(zé)為該分區(qū)選舉新的 leader 副本。當(dāng)檢測(cè)到某個(gè)分區(qū)的 ISR(In-Sync Replica)集合發(fā)生變化時(shí)，由控制器負(fù)責(zé)通知所有 broker 更新其元數(shù)據(jù)信息。當(dāng)使用kafka-topics.sh腳本為某個(gè) topic 增加分區(qū)數(shù)量時(shí)，同樣還是由控制器負(fù)責(zé)分區(qū)的重新分配。

Kafka 中 Contorller 的選舉的工作依賴于 Zookeeper，成功競(jìng)選為控制器的 broker 會(huì)在 Zookeeper 中創(chuàng)建/controller這個(gè)臨時(shí)（EPHEMERAL）節(jié)點(diǎn)。

選舉過(guò)程

Broker 啟動(dòng)的時(shí)候嘗試去讀取/controller節(jié)點(diǎn)的brokerid的值，如果brokerid的值不等于-1，則表明已經(jīng)有其他的 Broker 成功成為 Controller 節(jié)點(diǎn)，當(dāng)前 Broker 主動(dòng)放棄競(jìng)選；如果不存在/controller節(jié)點(diǎn)，或者 brokerid 數(shù)值異常，當(dāng)前 Broker 嘗試去創(chuàng)建/controller這個(gè)節(jié)點(diǎn)，此時(shí)也有可能其他 broker 同時(shí)去嘗試創(chuàng)建這個(gè)節(jié)點(diǎn)，只有創(chuàng)建成功的那個(gè) broker 才會(huì)成為控制器，而創(chuàng)建失敗的 broker 則表示競(jìng)選失敗。每個(gè) broker 都會(huì)在內(nèi)存中保存當(dāng)前控制器的 brokerid 值，這個(gè)值可以標(biāo)識(shí)為 activeControllerId。

實(shí)現(xiàn)

Controller 讀取 Zookeeper 中的節(jié)點(diǎn)數(shù)據(jù)，初始化上下文(Controller Context)，并管理節(jié)點(diǎn)變化，變更上下文，同時(shí)也需要將這些變更信息同步到其他普通的 broker 節(jié)點(diǎn)中。Controller 通過(guò)定時(shí)任務(wù)，或者監(jiān)聽(tīng)器模式獲取 zookeeper 信息，事件監(jiān)聽(tīng)會(huì)更新更新上下文信息，如圖所示，Controller 內(nèi)部也采用生產(chǎn)者-消費(fèi)者實(shí)現(xiàn)模式，Controller 將 zookeeper 的變動(dòng)通過(guò)事件的方式發(fā)送給事件隊(duì)列，隊(duì)列就是一個(gè)LinkedBlockingQueue，事件消費(fèi)者線程組通過(guò)消費(fèi)消費(fèi)事件，將相應(yīng)的事件同步到各 Broker 節(jié)點(diǎn)。這種隊(duì)列 FIFO 的模式保證了消息的有序性。

職責(zé)

Controller 被選舉出來(lái)，作為整個(gè) Broker 集群的管理者，管理所有的集群信息和元數(shù)據(jù)信息。它的職責(zé)包括下面幾部分：

1. 處理 Broker 節(jié)點(diǎn)的上線和下線，包括自然下線、宕機(jī)和網(wǎng)絡(luò)不可達(dá)導(dǎo)致的集群變動(dòng)，Controller 需要及時(shí)更新集群元數(shù)據(jù)，并將集群變化通知到所有的 Broker 集群節(jié)點(diǎn)；
2. 創(chuàng)建 Topic 或者 Topic 擴(kuò)容分區(qū)，Controller 需要負(fù)責(zé)分區(qū)副本的分配工作，并主導(dǎo) Topic 分區(qū)副本的 Leader 選舉。
3. 管理集群中所有的副本和分區(qū)的狀態(tài)機(jī)，監(jiān)聽(tīng)狀態(tài)機(jī)變化事件，并作出相應(yīng)的處理。Kafka 分區(qū)和副本數(shù)據(jù)采用狀態(tài)機(jī)的方式管理，分區(qū)和副本的變化都在狀態(tài)機(jī)內(nèi)會(huì)引起狀態(tài)機(jī)狀態(tài)的變更，從而觸發(fā)相應(yīng)的變化事件。

“

65 哥：狀態(tài)機(jī)啊，聽(tīng)起來(lái)好復(fù)雜。

”

Controller 管理著集群中所有副本和分區(qū)的狀態(tài)機(jī)。大家不要被狀態(tài)機(jī)這個(gè)詞唬住了。理解狀態(tài)機(jī)很簡(jiǎn)單。先理解模型，即這是什么關(guān)于什么模型，然后就是模型的狀態(tài)有哪些，模型狀態(tài)之間如何轉(zhuǎn)換，轉(zhuǎn)換時(shí)發(fā)送相應(yīng)的變化事件。

Kafka 的分區(qū)和副本狀態(tài)機(jī)很簡(jiǎn)單。我們先理解，這分別是管理 Kafka Topic 的分區(qū)和副本的。它們的狀態(tài)也很簡(jiǎn)單，就是 CRUD，具體說(shuō)來(lái)如下：

分區(qū)狀態(tài)機(jī)

PartitionStateChange，管理 Topic 的分區(qū)，它有以下 4 種狀態(tài)：

1. NonExistentPartition：該狀態(tài)表示分區(qū)沒(méi)有被創(chuàng)建過(guò)或創(chuàng)建后被刪除了。
2. NewPartition：分區(qū)剛創(chuàng)建后，處于這個(gè)狀態(tài)。此狀態(tài)下分區(qū)已經(jīng)分配了副本，但是還沒(méi)有選舉 leader，也沒(méi)有 ISR 列表。
3. OnlinePartition：一旦這個(gè)分區(qū)的 leader 被選舉出來(lái)，將處于這個(gè)狀態(tài)。
4. OfflinePartition：當(dāng)分區(qū)的 leader 宕機(jī)，轉(zhuǎn)移到這個(gè)狀態(tài)。

我們用一張圖來(lái)直觀的看看這些狀態(tài)是如何變化的，以及在狀態(tài)發(fā)生變化時(shí) Controller 都有哪些操作：

副本狀態(tài)機(jī)

ReplicaStateChange，副本狀態(tài)，管理分區(qū)副本信息，它也有 4 種狀態(tài)：

1. NewReplica: 創(chuàng)建 topic 和分區(qū)分配后創(chuàng)建 replicas，此時(shí)，replica 只能獲取到成為 follower 狀態(tài)變化請(qǐng)求。
2. OnlineReplica: 當(dāng) replica 成為 parition 的 assingned replicas 時(shí)，其狀態(tài)變?yōu)?OnlineReplica, 即一個(gè)有效的 OnlineReplica。
3. OfflineReplica: 當(dāng)一個(gè) replica 下線，進(jìn)入此狀態(tài)，這一般發(fā)生在 broker 宕機(jī)的情況下；
4. NonExistentReplica: Replica 成功刪除后，replica 進(jìn)入 NonExistentReplica 狀態(tài)。

副本狀態(tài)間的變化如下圖所示，Controller 在狀態(tài)變化時(shí)會(huì)做出相應(yīng)的操作：

Network

Kafka 的網(wǎng)絡(luò)通信模型是基于 NIO 的 Reactor 多線程模型來(lái)設(shè)計(jì)的。其中包含了一個(gè)Acceptor線程，用于處理新的連接，Acceptor 有 N 個(gè) Processor 線程 select 和 read socket 請(qǐng)求，N 個(gè) Handler 線程處理請(qǐng)求并相應(yīng)，即處理業(yè)務(wù)邏輯。下面就是 KafkaServer 的模型圖：

之后的 Kafka 源碼篇，[碼哥]將從源碼的角度來(lái)講解這些原理在代碼上的具體實(shí)現(xiàn)，各位敬請(qǐng)期待啊。

往期回顧

1. Kafka 性能篇：為何 Kafka 這么"快"？
2. 從面試角度一文學(xué)完 Kafka
3. 不可不知的軟件架構(gòu)模式
4. Redis 日志篇：無(wú)畏宕機(jī)快速恢復(fù)的殺手锏

文章如有錯(cuò)誤，感謝指正，關(guān)注我，獲取真正的硬核知識(shí)點(diǎn)。另外技術(shù)讀者群也開(kāi)通了，后臺(tái)回復(fù)「加群」獲取「碼哥字節(jié)」作者微信，一起成長(zhǎng)交流。

以上就是本篇所有內(nèi)容覺(jué)得不錯(cuò)請(qǐng)點(diǎn)贊、分享，「碼哥字節(jié)」感激不盡。