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