Kafka能有什么壞心思，不過(guò)是被Zookeeper害慘了……

作者：jinjunzhu 2021-05-20 09:06:20

最近，confluent社區(qū)發(fā)表了一篇文章，主要講述了Kafka未來(lái)的2.8版本將要放棄Zookeeper，這對(duì)于Kafka用戶來(lái)說(shuō)，是一個(gè)重要的改進(jìn)。之前部署Kafka就必須得部署Zookeeper，而之后就只要單獨(dú)部署Kafka就行了。

一、Kafka簡(jiǎn)介

Apache Kafka最早是由Linkedin公司開發(fā)，后來(lái)捐獻(xiàn)給了Apack基金會(huì)。

Kafka被官方定義為分布式流式處理平臺(tái)，因?yàn)榫邆涓咄掏隆⒖沙志没⒖伤綌U(kuò)展等特性而被廣泛使用。目前Kafka具體如下功能：

消息隊(duì)列,Kafka具有系統(tǒng)解耦、流量削峰、緩沖、異步通信等消息隊(duì)列的功能。
分布式存儲(chǔ)系統(tǒng)，Kafka可以把消息持久化，同時(shí)用多副本來(lái)實(shí)現(xiàn)故障轉(zhuǎn)移，可以作為數(shù)據(jù)存儲(chǔ)系統(tǒng)來(lái)使用。
實(shí)時(shí)數(shù)據(jù)處理，Kafka提供了一些和數(shù)據(jù)處理相關(guān)的組件，比如Kafka Streams、Kafka Connect，具備了實(shí)時(shí)數(shù)據(jù)的處理功能。

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

通過(guò)上面這張圖，介紹一下Kafka中的幾個(gè)主要概念：

producer和consumer: 消息隊(duì)列中的生產(chǎn)者和消費(fèi)者，生產(chǎn)者將消息推送到隊(duì)列，消費(fèi)者從隊(duì)列中拉取消息。
consumer group:消費(fèi)者集合，這些消費(fèi)者可以并行消費(fèi)同一個(gè)topic下不同partition中的消息。
broker：Kafka集群中的服務(wù)器。
topic：消息的分類。
partition：topic物理上的分組，一個(gè)topic可以有partition，每個(gè)partition中的消息會(huì)被分配一個(gè)有序的id作為offset。每個(gè)consumer group只能有一個(gè)消費(fèi)者來(lái)消費(fèi)一個(gè)partition。

二、Kafka和Zookeeper關(guān)系

Kafka架構(gòu)如下圖：

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

看下面這張圖：

1、注冊(cè)中心

1)broker注冊(cè)

從上面的圖中可以看到，broker分布式部署，就需要一個(gè)注冊(cè)中心來(lái)進(jìn)行統(tǒng)一管理。Zookeeper用一個(gè)專門節(jié)點(diǎn)保存Broker服務(wù)列表，也就是 /brokers/ids。

broker在啟動(dòng)時(shí)，向Zookeeper發(fā)送注冊(cè)請(qǐng)求，Zookeeper會(huì)在/brokers/ids下創(chuàng)建這個(gè)broker節(jié)點(diǎn)，如/brokers/ids/[0...N]，并保存broker的IP地址和端口。

這個(gè)節(jié)點(diǎn)臨時(shí)節(jié)點(diǎn)，一旦broker宕機(jī)，這個(gè)臨時(shí)節(jié)點(diǎn)會(huì)被自動(dòng)刪除。

2) topic注冊(cè)

Zookeeper也會(huì)為topic分配一個(gè)單獨(dú)節(jié)點(diǎn)，每個(gè)topic都會(huì)以/brokers/topics/[topic_name]的形式記錄在Zookeeper。

一個(gè)topic的消息會(huì)被保存到多個(gè)partition，這些partition跟broker的對(duì)應(yīng)關(guān)系也需要保存到Zookeeper。

partition是多副本保存的，上圖中紅色partition是leader副本。當(dāng)leader副本所在的broker發(fā)生故障時(shí)，partition需要重新選舉leader，這個(gè)需要由Zookeeper主導(dǎo)完成。

broker啟動(dòng)后，會(huì)把自己的Broker ID注冊(cè)到到對(duì)應(yīng)topic節(jié)點(diǎn)的分區(qū)列表中。

我們查看一個(gè)topic是xxx，分區(qū)編號(hào)是1的信息，命令如下：

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

當(dāng)broker退出后，Zookeeper會(huì)更新其對(duì)應(yīng)topic的分區(qū)列表。

3)consumer注冊(cè)

消費(fèi)者組也會(huì)向Zookeeper進(jìn)行注冊(cè)，Zookeeper會(huì)為其分配節(jié)點(diǎn)來(lái)保存相關(guān)數(shù)據(jù)，節(jié)點(diǎn)路徑為/consumers/{group_id}，有3個(gè)子節(jié)點(diǎn)，如下圖:

這樣Zookeeper可以記錄分區(qū)跟消費(fèi)者的關(guān)系，以及分區(qū)的offset。[3]

2、負(fù)載均衡

broker向Zookeeper進(jìn)行注冊(cè)后，生產(chǎn)者根據(jù)broker節(jié)點(diǎn)來(lái)感知broker服務(wù)列表變化，這樣可以實(shí)現(xiàn)動(dòng)態(tài)負(fù)載均衡。

consumer group中的消費(fèi)者，可以根據(jù)topic節(jié)點(diǎn)信息來(lái)拉取特定分區(qū)的消息,實(shí)現(xiàn)負(fù)載均衡。

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

隨著broker、topic和partition增多，保存的數(shù)據(jù)量會(huì)越來(lái)越大。

三、Controller介紹

經(jīng)過(guò)上一節(jié)的講述，我們看到了Kafka對(duì)Zookeeper的依賴非常大，Kafka離開Zookeeper是沒有辦法獨(dú)立運(yùn)行的。那Kafka是怎么跟Zookeeper進(jìn)行交互的呢?

如下圖：[4]

Kafka集群中會(huì)有一個(gè)broker被選舉為Controller負(fù)責(zé)跟Zookeeper進(jìn)行交互，它負(fù)責(zé)管理整個(gè)Kafka集群中所有分區(qū)和副本的狀態(tài)。其他broker監(jiān)聽Controller節(jié)點(diǎn)的數(shù)據(jù)變化。

Controller的選舉工作依賴于Zookeeper，選舉成功后，Zookeeper會(huì)創(chuàng)建一個(gè)/controller臨時(shí)節(jié)點(diǎn)。

Controller具體職責(zé)如下：

監(jiān)聽分區(qū)變化

比如當(dāng)某個(gè)分區(qū)的leader出現(xiàn)故障時(shí)，Controller會(huì)為該分區(qū)選舉新的leader。當(dāng)檢測(cè)到分區(qū)的ISR集合發(fā)生變化時(shí)，Controller會(huì)通知所有broker更新元數(shù)據(jù)。當(dāng)某個(gè)topic增加分區(qū)時(shí)，Controller會(huì)負(fù)責(zé)重新分配分區(qū)。

監(jiān)聽topic相關(guān)的變化
監(jiān)聽broker相關(guān)的變化
集群元數(shù)據(jù)管理

下面這張圖展示了Controller、Zookeeper和broker的交互細(xì)節(jié)：

Controller選舉成功后，會(huì)從Zookeeper集群中拉取一份完整的元數(shù)據(jù)初始化ControllerContext，這些元數(shù)據(jù)緩存在Controller節(jié)點(diǎn)。當(dāng)集群發(fā)生變化時(shí)，比如增加topic分區(qū)，Controller不僅需要變更本地的緩存數(shù)據(jù)，還需要將這些變更信息同步到其他Broker。

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

四、Zookeeper帶來(lái)的問題

Kafka本身就是一個(gè)分布式系統(tǒng)，但是需要另一個(gè)分布式系統(tǒng)來(lái)管理，復(fù)雜性無(wú)疑增加了。

1、運(yùn)維復(fù)雜度

使用了Zookeeper，部署Kafka的時(shí)候必須要部署兩套系統(tǒng)，Kafka的運(yùn)維人員必須要具備Zookeeper的運(yùn)維能力。

2、Controller故障處理

Kafka依賴一個(gè)單一Controller節(jié)點(diǎn)跟Zookeeper進(jìn)行交互，如果這個(gè)Controller節(jié)點(diǎn)發(fā)生了故障，就需要從broker中選擇新的Controller。如下圖,新的Controller變成了broker3。

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

3、分區(qū)瓶頸

當(dāng)分區(qū)數(shù)增加時(shí)，Zookeeper保存的元數(shù)據(jù)變多，Zookeeper集群壓力變大，達(dá)到一定級(jí)別后，監(jiān)聽延遲增加，給Kafka的工作帶來(lái)了影響。

所以，Kafka單集群承載的分區(qū)數(shù)量是一個(gè)瓶頸。而這又恰恰是一些業(yè)務(wù)場(chǎng)景需要的。

五、升級(jí)

升級(jí)前后的架構(gòu)圖對(duì)比如下：

KIP-500用Quorum Controller代替之前的Controller，Quorum中每個(gè)Controller節(jié)點(diǎn)都會(huì)保存所有元數(shù)據(jù)，通過(guò)KRaft協(xié)議保證副本的一致性。這樣即使Quorum Controller節(jié)點(diǎn)出故障了，新的Controller遷移也會(huì)非常快。

官方介紹，升級(jí)之后，Kafka可以輕松支持百萬(wàn)級(jí)別的分區(qū)。

Kafak團(tuán)隊(duì)把通過(guò)Raft協(xié)議同步數(shù)據(jù)的方式Kafka Raft Metadata mode,簡(jiǎn)稱KRaft

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

目前去除Zookeeper的Kafka代碼KIP-500已經(jīng)提交到trunk分支，并且已經(jīng)在的2.8版本發(fā)布。

Kafka計(jì)劃在3.0版本會(huì)兼容Zookeeper Controller和Quorum Controller，這樣用戶可以進(jìn)行灰度測(cè)試。[5]