如何理解Kafka和Zookeeper的關系

這篇文章主要講解了“如何理解Kafka和Zookeeper的關系”，文中的講解內容簡單清晰，易于學習與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學習“如何理解Kafka和Zookeeper的關系”吧！

1.Kafka簡介

Apache Kafka最早是由Linkedin公司開發，后來捐獻給了Apack基金會。

Kafka被官方定義為分布式流式處理平臺，因為具備高吞吐、可持久化、可水平擴展等特性而被廣泛使用。目前Kafka具體如下功能：

• 消息隊列,Kafka具有系統解耦、流量削峰、緩沖、異步通信等消息隊列的功能。

• 分布式存儲系統，Kafka可以把消息持久化，同時用多副本來實現故障轉移，可以作為數據存儲系統來使用。

• 實時數據處理，Kafka提供了一些和數據處理相關的組件，比如Kafka Streams、Kafka Connect，具備了實時數據的處理功能。

下面這張圖是Kafka的消息模型：[2]

通過上面這張圖，介紹一下Kafka中的幾個主要概念：

• producer和consumer: 消息隊列中的生產者和消費者，生產者將消息推送到隊列，消費者從隊列中拉取消息。

• consumer group:消費者集合，這些消費者可以并行消費同一個topic下不同partition中的消息。

• broker：Kafka集群中的服務器。

• topic：消息的分類。

• partition：topic物理上的分組，一個topic可以有partition，每個partition中的消息會被分配一個有序的id作為offset。每個consumer  group只能有一個消費者來消費一個partition。

2.Kafka和Zookeeper關系

Kafka架構如下圖：圖片從圖中可以看到，Kafka的工作需要Zookeeper的配合。那他們到底是怎么配合工作呢?

看下面這張圖：

從圖中可以看到，Kafka的工作需要Zookeeper的配合。那他們到底是怎么配合工作呢？

看下面這張圖：

2.1 注冊中心

2.1.1 broker注冊

從上面的圖中可以看到，broker分布式部署，就需要一個注冊中心來進行統一管理。Zookeeper用一個專門節點保存Broker服務列表，也就是  /brokers/ids。

broker在啟動時，向Zookeeper發送注冊請求，Zookeeper會在/brokers/ids下創建這個broker節點，如/brokers/ids/[0...N]，并保存broker的IP地址和端口。

這個節點臨時節點，一旦broker宕機，這個臨時節點會被自動刪除。

2.1.2 topic注冊

Zookeeper也會為topic分配一個單獨節點，每個topic都會以/brokers/topics/[topic_name]的形式記錄在Zookeeper。

一個topic的消息會被保存到多個partition，這些partition跟broker的對應關系也需要保存到Zookeeper。

partition是多副本保存的，上圖中紅色partition是leader副本。當leader副本所在的broker發生故障時，partition需要重新選舉leader，這個需要由Zookeeper主導完成。

broker啟動后，會把自己的Broker ID注冊到到對應topic節點的分區列表中。

我們查看一個topic是xxx，分區編號是1的信息，命令如下：

[root@master] get /brokers/topics/xxx/partitions/1/state {"controller_epoch":15,"leader":11,"version":1,"leader_epoch":2,"isr":[11,12,13]}

當broker退出后，Zookeeper會更新其對應topic的分區列表。

2.1.3 consumer注冊

消費者組也會向Zookeeper進行注冊，Zookeeper會為其分配節點來保存相關數據，節點路徑為/consumers/{group_id}，有3個子節點，如下圖:

這樣Zookeeper可以記錄分區跟消費者的關系，以及分區的offset。[3]

2.2 負載均衡

broker向Zookeeper進行注冊后，生產者根據broker節點來感知broker服務列表變化，這樣可以實現動態負載均衡。

consumer group中的消費者，可以根據topic節點信息來拉取特定分區的消息,實現負載均衡。

實際上，Kafka在Zookeeper中保存的元數據非常多，看下面這張圖：

隨著broker、topic和partition增多，保存的數據量會越來越大。

3.Controller介紹

經過上一節的講述，我們看到了Kafka對Zookeeper的依賴非常大，Kafka離開Zookeeper是沒有辦法獨立運行的。那Kafka是怎么跟Zookeeper進行交互的呢?

如下圖：[4]圖片Kafka集群中會有一個broker被選舉為Controller負責跟Zookeeper進行交互，它負責管理整個Kafka集群中所有分區和副本的狀態。其他broker監聽Controller節點的數據變化。

Controller的選舉工作依賴于Zookeeper，選舉成功后，Zookeeper會創建一個/controller臨時節點。

Controller具體職責如下：

• 監聽分區變化

比如當某個分區的leader出現故障時，Controller會為該分區選舉新的leader。當檢測到分區的ISR集合發生變化時，Controller會通知所有broker更新元數據。當某個topic增加分區時，Controller會負責重新分配分區。

• 監聽topic相關的變化

• 監聽broker相關的變化

• 集群元數據管理

下面這張圖展示了Controller、Zookeeper和broker的交互細節：

Controller選舉成功后，會從Zookeeper集群中拉取一份完整的元數據初始化ControllerContext，這些元數據緩存在Controller節點。當集群發生變化時，比如增加topic分區，Controller不僅需要變更本地的緩存數據，還需要將這些變更信息同步到其他Broker。

Controller監聽到Zookeeper事件、定時任務事件和其他事件后，將這些事件按照先后順序暫存到LinkedBlockingQueue中，由事件處理線程按順序處理，這些處理多數需要跟Zookeeper交互，Controller則需要更新自己的元數據。

4.Zookeeper帶來的問題

Kafka本身就是一個分布式系統，但是需要另一個分布式系統來管理，復雜性無疑增加了。

4.1 運維復雜度

使用了Zookeeper，部署Kafka的時候必須要部署兩套系統，Kafka的運維人員必須要具備Zookeeper的運維能力。

4.2 Controller故障處理

Kafaka依賴一個單一Controller節點跟Zookeeper進行交互，如果這個Controller節點發生了故障，就需要從broker中選擇新的Controller。如下圖,新的Controller變成了broker3。

新的Controller選舉成功后，會重新從Zookeeper拉取元數據進行初始化，并且需要通知其他所有的broker更新ActiveControllerId。老的Controller需要關閉監聽、事件處理線程和定時任務。分區數非常多時，這個過程非常耗時，而且這個過程中Kafka集群是不能工作的。

4.3 分區瓶頸

當分區數增加時，Zookeeper保存的元數據變多，Zookeeper集群壓力變大，達到一定級別后，監聽延遲增加，給Kafaka的工作帶來了影響。

所以，Kafka單集群承載的分區數量是一個瓶頸。而這又恰恰是一些業務場景需要的。

5.升級

升級前后的架構圖對比如下：

KIP-500用Quorum  Controller代替之前的Controller，Quorum中每個Controller節點都會保存所有元數據，通過KRaft協議保證副本的一致性。這樣即使Quorum  Controller節點出故障了，新的Controller遷移也會非常快。

官方介紹，升級之后，Kafka可以輕松支持百萬級別的分區。

Kafak團隊把通過Raft協議同步數據的方式Kafka Raft Metadata mode,簡稱KRaft

Kafka的用戶體量非常大，在不停服的情況下升級是必要的。

目前去除Zookeeper的Kafka代碼KIP-500已經提交到trunk分支，并且計劃在未來的2.8版本發布。

Kafaka計劃在3.0版本會兼容Zookeeper Controller和Quorum Controller，這樣用戶可以進行灰度測試。[5]

感謝各位的閱讀，以上就是“如何理解Kafka和Zookeeper的關系”的內容了，經過本文的學習后，相信大家對如何理解Kafka和Zookeeper的關系這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是億速云，小編將為大家推送更多相關知識點的文章，歡迎關注！