Kafka原理篇：圖解kakfa架構(gòu)原理
這是[碼哥]Kafka 系列文章的第二篇，碼哥將從原理、實(shí)踐和源碼角度為大家深入剖析并實(shí)踐 Kafka。此系列包括[原理篇]、[實(shí)踐篇]和[源碼篇]。這篇是[原理篇]的第二篇，主要講解 Kafka 的架構(gòu)和實(shí)現(xiàn)原理。
讀者可以回顧之前的文章《Kafka 性能篇：為何 Kafka 這么"快"?》。
今天我們來深入講解 Kafka 的架構(gòu)和實(shí)現(xiàn)原理。[碼哥]將從架構(gòu)和細(xì)節(jié)入手，以生動(dòng)的圖深入講解 Kafka 的實(shí)現(xiàn)原理。
我想很多同學(xué)之前可能已經(jīng)看過很多 Kafka 原理相關(guān)的文章，但往往看時(shí)"牛逼"聲連連，激情滿滿，總覺得自己又學(xué)習(xí)到了各種“吊炸天”的技術(shù)。但很多同學(xué)往往是不覺明厲，把文章結(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 配置說明鏈接：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 原理
開篇寄語
盡可能做一些產(chǎn)品出來，有一個(gè)作品很重要，這是別人了解你的窗口。如果可能，給自己開一個(gè)公眾號(hào)或者一個(gè)博客，記錄自己每天的見聞思考。剛開始記會(huì)很凌亂沒有邏輯，但堅(jiān)持下去一定會(huì)有很大價(jià)值。
Architecture
理解 Kafka 架構(gòu)，就是理解 Kafka 的各種組件的概念，以及這些組件的關(guān)系。先簡(jiǎn)單看一下各組件及其簡(jiǎn)單說明。
不要去嘗試記憶他們
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 就是通過消費(fè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 通過它來保證消息在分區(qū)內(nèi)的順序性，不過 offset 并不跨越分區(qū)，也就是說，Kafka 保證的是分區(qū)有序性而不是主題有序性。
Replication： 副本，是 Kafka 保證數(shù)據(jù)高可用的方式，Kafka 同一 Partition 的數(shù)據(jù)可以在多 Broker 上存在多個(gè)副本，通常只有主副本對(duì)外提供讀寫服務(wù)，當(dāng)主副本所在 broker 崩潰或發(fā)生網(wǎng)絡(luò)異常，Kafka 會(huì)在 Controller 的管理下會(huì)重新選擇新的 Leader 副本對(duì)外提供讀寫服務(wù)。
Record： 實(shí)際寫入 Kafka 中并可以被讀取的消息記錄。每個(gè) record 包含了 key、value 和 timestamp。
我們理解了也就自然記住了
我們應(yīng)該通過理解的方式去記憶它們。
生產(chǎn)者-消費(fèi)者
生產(chǎn)者-消費(fèi)者是一種設(shè)計(jì)模式，生產(chǎn)者和消費(fèi)者之間通過添加一個(gè)中間組件來達(dá)到解耦。生產(chǎn)者向中間組件生成數(shù)據(jù)，消費(fèi)者消費(fèi)數(shù)據(jù)。
就像 65 哥讀書時(shí)給小芳寫情書，這里 65 哥就是生產(chǎn)者，情書就是消息，小芳就是消費(fèi)者。但有時(shí)候小芳不在，或者比較忙，65 哥也比較害羞，不敢直接將情書塞小芳手里，于是將情書塞在小芳抽屜中。所以抽屜就是這個(gè)中間組件。
在程序中我們通常使用Queue來作為這個(gè)中間組件?？梢允褂枚嗑€程向隊(duì)列中寫入數(shù)據(jù)，另外的消費(fèi)者線程依次讀取隊(duì)列中的數(shù)據(jù)進(jìn)行消費(fèi)。模型如下圖所示：
生產(chǎn)者-消費(fèi)者模式通過添加一個(gè)中間層，不僅可以解耦生產(chǎn)者和消費(fèi)者，使其易于擴(kuò)展，還可以異步化調(diào)用、緩沖消息等。
分布式隊(duì)列
后來 65 哥和小芳異地了，65 哥在卷都奮斗，小芳在魔都逛街。于是只能通過郵局寄曖昧信了。這樣 65 哥、郵局和小芳就成了分布式的了。65 哥將信件發(fā)給郵局，小芳從郵局拿到 65 哥寫的信，再回去慢慢看。
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 哥一天寫好幾封信。但也無法挽回郵局的損失。所以郵局是可以供任何人寄信。只需要寄信人寫好地址(主題)，郵局建有兩地的通道就可以發(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 哥寫的信太多，一個(gè)郵局已經(jīng)無法滿足 65 哥的需求，郵政公司只能多建幾個(gè)郵局了，65 哥將信件按私密度分類(分區(qū)策略)，從不同的郵局寄送。
同一個(gè) Topic 可以創(chuàng)建多個(gè)分區(qū)。理論上分區(qū)越多并發(fā)度越高，Kafka 會(huì)根據(jù)分區(qū)策略將分區(qū)盡可能均衡的分布在不同的 Broker 節(jié)點(diǎn)上，以避免消息傾斜，不同的 Broker 負(fù)載差異太大。分區(qū)也不是越多越好哦，畢竟太多郵政公司也管理不過來。具體的原因可以參考[碼哥]之前的文章《Kafka 性能篇：為何 Kafka 這么"快"?》
副本
為防止由于郵局的問題，比如交通斷啦，郵車沒油啦。導(dǎo)致 65 哥的曖昧信無法寄到小芳手上，使得 65 哥晚上遠(yuǎn)程跪鍵盤。郵局決定將 65 哥的信件復(fù)制幾份發(fā)到多個(gè)正常的郵局，這樣只要有一個(gè)郵局還在，小芳就可以收到 65 哥的信了。
Kafka 采用分區(qū)副本的方式來保證數(shù)據(jù)的高可用，每個(gè)分區(qū)都將建立指定數(shù)量的副本數(shù)，kakfa 保證同一分區(qū)副本盡量分布在不同的 Broker 節(jié)點(diǎn)上，以防止 Broker 宕機(jī)導(dǎo)致所有副本不可用。Kafka 會(huì)為分區(qū)的多個(gè)副本選舉一個(gè)作為主副本(Leader)，主副本對(duì)外提供讀寫服務(wù)，從副本(Follower)實(shí)時(shí)同步 Leader 的數(shù)據(jù)。
多消費(fèi)者
哎，65 哥的信件滿天飛，小芳天天跑郵局，還要一一拆開看，65 哥寫的信又臭又長(zhǎng)，讓小芳忙得滿身大漢大汗。于是小芳啪的一下，很快啊，變出多個(gè)分身去不同的郵局取信，這樣小芳終于可以擠出額外的時(shí)間逛街了。
廣播消息
郵局最近提供了定制明信片業(yè)務(wù)，每個(gè)人都可以設(shè)計(jì)明信片，同一個(gè)身份只能領(lǐng)取一種明信片。65 哥設(shè)計(jì)了一堆，廣播給所有漂亮的小妹妹都可以來領(lǐng)取，美女啪變出的分身也可以來領(lǐng)取，但是同一個(gè)身份的多個(gè)分身只能取一種明信片。
Kafka 通過 Consumer Group 來實(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 上。通過在 Zookeeper 上建立相應(yīng)的數(shù)據(jù)節(jié)點(diǎn)，并監(jiān)聽節(jié)點(diǎn)的變化，Kafka 使用 Zookeeper 完成以下功能：
- Kafka Controller 的 Leader 選舉
- Kafka 集群成員管理
- Topic 配置管理
- 分區(qū)副本管理
我們看一看 Zookeeper 下 Kafka 創(chuàng)建的節(jié)點(diǎn)，即可一目了然的看出這些相關(guān)的功能。
Controller
Controller 是從 Broker 中選舉出來的，負(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)。
選舉過程
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 通過定時(shí)任務(wù)，或者監(jiān)聽器模式獲取 zookeeper 信息，事件監(jiān)聽會(huì)更新更新上下文信息，如圖所示，Controller 內(nèi)部也采用生產(chǎn)者-消費(fèi)者實(shí)現(xiàn)模式，Controller 將 zookeeper 的變動(dòng)通過事件的方式發(fā)送給事件隊(duì)列，隊(duì)列就是一個(gè)LinkedBlockingQueue，事件消費(fèi)者線程組通過消費(fèi)消費(fèi)事件，將相應(yīng)的事件同步到各 Broker 節(jié)點(diǎn)。這種隊(duì)列 FIFO 的模式保證了消息的有序性。
職責(zé)
Controller 被選舉出來，作為整個(gè) Broker 集群的管理者，管理所有的集群信息和元數(shù)據(jù)信息。它的職責(zé)包括下面幾部分：
處理 Broker 節(jié)點(diǎn)的上線和下線，包括自然下線、宕機(jī)和網(wǎng)絡(luò)不可達(dá)導(dǎo)致的集群變動(dòng)，Controller 需要及時(shí)更新集群元數(shù)據(jù)，并將集群變化通知到所有的 Broker 集群節(jié)點(diǎn);
創(chuàng)建 Topic 或者 Topic 擴(kuò)容分區(qū)，Controller 需要負(fù)責(zé)分區(qū)副本的分配工作，并主導(dǎo) Topic 分區(qū)副本的 Leader 選舉。
管理集群中所有的副本和分區(qū)的狀態(tài)機(jī)，監(jiān)聽狀態(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ī)啊，聽起來好復(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，具體說來如下：
分區(qū)狀態(tài)機(jī)
PartitionStateChange，管理 Topic 的分區(qū)，它有以下 4 種狀態(tài)：
- NonExistentPartition：該狀態(tài)表示分區(qū)沒有被創(chuàng)建過或創(chuàng)建后被刪除了。
- NewPartition：分區(qū)剛創(chuàng)建后，處于這個(gè)狀態(tài)。此狀態(tài)下分區(qū)已經(jīng)分配了副本，但是還沒有選舉 leader，也沒有 ISR 列表。
- OnlinePartition：一旦這個(gè)分區(qū)的 leader 被選舉出來，將處于這個(gè)狀態(tài)。
- OfflinePartition：當(dāng)分區(qū)的 leader 宕機(jī)，轉(zhuǎn)移到這個(gè)狀態(tài)。
我們用一張圖來直觀的看看這些狀態(tài)是如何變化的，以及在狀態(tài)發(fā)生變化時(shí) Controller 都有哪些操作：
副本狀態(tài)機(jī)
ReplicaStateChange，副本狀態(tài)，管理分區(qū)副本信息，它也有 4 種狀態(tài)：
- NewReplica: 創(chuàng)建 topic 和分區(qū)分配后創(chuàng)建 replicas，此時(shí)，replica 只能獲取到成為 follower 狀態(tài)變化請(qǐng)求。
- OnlineReplica: 當(dāng) replica 成為 parition 的 assingned replicas 時(shí)，其狀態(tài)變?yōu)? OnlineReplica, 即一個(gè)有效的 OnlineReplica。
- OfflineReplica: 當(dāng)一個(gè) replica 下線，進(jìn)入此狀態(tài)，這一般發(fā)生在 broker 宕機(jī)的情況下;
- NonExistentReplica: Replica 成功刪除后，replica 進(jìn)入 NonExistentReplica 狀態(tài)。
副本狀態(tài)間的變化如下圖所示，Controller 在狀態(tài)變化時(shí)會(huì)做出相應(yīng)的操作：
Network
Kafka 的網(wǎng)絡(luò)通信模型是基于 NIO 的 Reactor 多線程模型來設(shè)計(jì)的。其中包含了一個(gè)Acceptor線程，用于處理新的連接，Acceptor 有 N 個(gè) Processor 線程 select 和 read socket 請(qǐng)求，N 個(gè) Handler 線程處理請(qǐng)求并相應(yīng)，即處理業(yè)務(wù)邏輯。下面就是 KafkaServer 的模型圖：
之后的 Kafka 源碼篇，[碼哥]將從源碼的角度來講解這些原理在代碼上的具體實(shí)現(xiàn)，各位敬請(qǐng)期待啊。
