• ZooKeeper 的作用
• 那為什么要拋棄 ZooKeeper
  • 先來看看運(yùn)維的層面的問題。
  • 再看性能層面的問題。
  • 基于 ZooKeeper 的性能問題 Kafka 之前就做了一些升級(jí)。
• 所以沒了 Zookeeper 之后的 Kafka 的怎樣的？
• 最后

在上個(gè)月 30 號(hào)， confluent 發(fā)布了一篇文章，文章上說在 Kafka 2.8 版本上將支持內(nèi)部的 quorum 服務(wù)來替換 ZooKeeper 的工作。

其實(shí)去年我寫的 Kafka 控制器事件處理全流程這篇文章已經(jīng)提到這一點(diǎn)。

今天再稍微展開來說說。

ZooKeeper 的作用

ZooKeeper 是一個(gè)開源的分布式協(xié)調(diào)服務(wù)框架，你也可以認(rèn)為它是一個(gè)可以保證一致性的分布式(小量)存儲(chǔ)系統(tǒng)。特別適合存儲(chǔ)一些公共的配置信息、集群的一些元數(shù)據(jù)等等。

它有持久節(jié)點(diǎn)和臨時(shí)節(jié)點(diǎn)，而臨時(shí)節(jié)點(diǎn)這個(gè)玩意再配合 Watcher 機(jī)制就很有用。

當(dāng)創(chuàng)建臨時(shí)節(jié)點(diǎn)的客戶端與 ZooKeeper 斷連之后，這個(gè)臨時(shí)節(jié)點(diǎn)就會(huì)消失，并且訂閱了節(jié)點(diǎn)狀態(tài)變更的客戶端會(huì)收到這個(gè)節(jié)點(diǎn)狀態(tài)變更的通知。

所以集群中某一服務(wù)上線或者下線，都可以被檢測(cè)到。因此可以用來實(shí)現(xiàn)服務(wù)發(fā)現(xiàn)，也可以實(shí)現(xiàn)故障轉(zhuǎn)移的監(jiān)聽機(jī)制。

Kafka 就是強(qiáng)依賴于 ZooKeeper，沒有 ZooKeeper 的話 Kafka 都無法運(yùn)行。ZooKeeper 為 Kafka 提供了元數(shù)據(jù)的管理，例如一些 Broker 的信息、主題數(shù)據(jù)、分區(qū)數(shù)據(jù)等等。

在每個(gè) Broker 啟動(dòng)的時(shí)候，都會(huì)和 ZooKeeper 進(jìn)行交互，這樣 ZooKeeper 就存儲(chǔ)了集群中所有的主題、配置、副本等信息。

還有一些選舉、擴(kuò)容等機(jī)制也都依賴 ZooKeeper 。

例如控制器的選舉：每個(gè) Broker 啟動(dòng)都會(huì)嘗試在 ZooKeeper 注冊(cè)/controller臨時(shí)節(jié)點(diǎn)來競(jìng)選控制器，第一個(gè)創(chuàng)建/controller節(jié)點(diǎn)的 Broker 會(huì)被指定為控制器。

競(jìng)爭(zhēng)失敗的節(jié)點(diǎn)也會(huì)依賴 watcher 機(jī)制，監(jiān)聽這個(gè)節(jié)點(diǎn)，如果控制器宕機(jī)了，那么其它 Broker 會(huì)繼續(xù)來爭(zhēng)搶，實(shí)現(xiàn)控制器的 failover。

從上面就可以得知 ZooKeeper 對(duì) Kafka 來說很重要 。

基于 Spring Boot + MyBatis Plus + Vue & Element 實(shí)現(xiàn)的后臺(tái)管理系統(tǒng) + 用戶小程序，支持 RBAC 動(dòng)態(tài)權(quán)限、多租戶、數(shù)據(jù)權(quán)限、工作流、三方登錄、支付、短信、商城等功能

• 項(xiàng)目地址：https://github.com/YunaiV/ruoyi-vue-pro
• 視頻教程：https://doc.iocoder.cn/video/

那為什么要拋棄 ZooKeeper

軟件架構(gòu)都是演進(jìn)的，之所以要變更那肯定是因?yàn)槌霈F(xiàn)了瓶頸。

先來看看運(yùn)維的層面的問題。

首先身為一個(gè)中間件，需要依賴另一個(gè)中間件，這就感覺有點(diǎn)奇怪。

你要說依賴 Netty 這種，那肯定是沒問題的。但是 Kafka 的運(yùn)行需要提供 ZooKeeper 集群，這其實(shí)有點(diǎn)怪怪的。

就等于如果你公司要上 Kafka 就得跟著上 ZooKeeper ，被動(dòng)了增加了運(yùn)維的復(fù)雜度。

好比你去商場(chǎng)買衣服，要買個(gè)上衣，服務(wù)員說不單賣，要買就得買一套，這錢是不是多花了？

所以運(yùn)維人員不僅得照顧 Kafka 集群，還得照顧 ZooKeeper 集群。

再看性能層面的問題。

ZooKeeper 有個(gè)特點(diǎn)，強(qiáng)一致性 。

如果 ZooKeeper 集群的某個(gè)節(jié)點(diǎn)的數(shù)據(jù)發(fā)生變更，則會(huì)通知其它 ZooKeeper 節(jié)點(diǎn)同時(shí)執(zhí)行更新，就得等著大家（超過半數(shù)）都寫完了才行，這寫入的性能就比較差了。

然后看到上面我說的小量 存儲(chǔ)系統(tǒng)了吧，一般而言，ZooKeeper 只適用于存儲(chǔ)一些簡(jiǎn)單的配置或者是集群的元數(shù)據(jù)，不是真正意義上的存儲(chǔ)系統(tǒng)。

如果寫入的數(shù)據(jù)量過大，ZooKeeper 的性能和穩(wěn)定性就會(huì)下降，可能導(dǎo)致 Watch 的延時(shí)或丟失。

所以在 Kafka 集群比較大，分區(qū)數(shù)很多的時(shí)候，ZooKeeper 存儲(chǔ)的元數(shù)據(jù)就會(huì)很多，性能就差了。

還有，ZooKeeper 也是分布式的，也需要選舉，它的選舉也不快，而且發(fā)生選舉的那段時(shí)候是不提供服務(wù)的！

基于 ZooKeeper 的性能問題 Kafka 之前就做了一些升級(jí)。

例如以前 Consumer 的位移數(shù)據(jù)是保存在 ZooKeeper 上的，所以當(dāng)提交位移或者獲取位移的時(shí)候都需要訪問 ZooKeeper ，這量一大 ZooKeeper 就頂不住。

所以后面引入了位移主題（Topic 是 __consumer_offsets），將位移的提交和獲取當(dāng)做消息一樣來處理，存儲(chǔ)在日志中，避免了頻繁訪問 ZooKeeper 性能差的問題。

還有像一些大公司，可能要支持百萬分區(qū)級(jí)別，這目前的 Kafka 單集群架構(gòu)下是無法支持穩(wěn)定運(yùn)行的，也就是目前單集群可以承載的分區(qū)數(shù)有限。

所以，Kafka 需要去 ZooKeeper 。

基于 Spring Cloud Alibaba + Gateway + Nacos + RocketMQ + Vue & Element 實(shí)現(xiàn)的后臺(tái)管理系統(tǒng) + 用戶小程序，支持 RBAC 動(dòng)態(tài)權(quán)限、多租戶、數(shù)據(jù)權(quán)限、工作流、三方登錄、支付、短信、商城等功能

• 項(xiàng)目地址：https://github.com/YunaiV/yudao-cloud
• 視頻教程：https://doc.iocoder.cn/video/

所以沒了 Zookeeper 之后的 Kafka 的怎樣的？

沒了 Zookeeper 的 Kafka 就把元數(shù)據(jù)存儲(chǔ)到自己內(nèi)部了，利用之前的 Log 存儲(chǔ)機(jī)制來保存元數(shù)據(jù)。

就和上面說到的位移主題一樣，會(huì)有一個(gè)元數(shù)據(jù)主題，元數(shù)據(jù)會(huì)像普通消息一樣保存在 Log 中。

所以元數(shù)據(jù)和之前的位移一樣，利用現(xiàn)有的消息存儲(chǔ)機(jī)制稍加改造來實(shí)現(xiàn)了功能，完美！

然后還搞了個(gè) KRaft 來實(shí)現(xiàn) Controller Quorum。

圖來自 confluent

這個(gè)協(xié)議是基于 Raft 的，協(xié)議具體就不展開了，就理解為它能解決 Controller Leader 的選舉，并且讓所有節(jié)點(diǎn)達(dá)成共識(shí)。

在之前基于 Zookeeper 實(shí)現(xiàn)的單個(gè) Controller 在分區(qū)數(shù)太大的時(shí)候還有個(gè)問題，故障轉(zhuǎn)移太慢了。

當(dāng) Controller 變更的時(shí)候，需要重新加載所有的元數(shù)據(jù)到新的 Controller 身上，并且需要把這些元數(shù)據(jù)同步給集群內(nèi)的所有 Broker。

而 Controller Quorum 中的 Leader 選舉切換則很快，因?yàn)樵獢?shù)據(jù)都已經(jīng)在 quorum 中同步了，也就是 quorum 的 Broker 都已經(jīng)有全部了元數(shù)據(jù)，所以不需要重新加載元數(shù)據(jù)！

并且其它 Broker 已經(jīng)基于 Log 存儲(chǔ)了一些元數(shù)據(jù)，所以只需要增量更新即可，不需要全量了。

這波改造下來就解決了之前元數(shù)據(jù)過多的問題，可以支持更多的分區(qū)！

最后

可能看到這里有人會(huì)說，那為何一開始不這么實(shí)現(xiàn)？

因?yàn)?ZooKeeper 是一個(gè)功能強(qiáng)大且經(jīng)過驗(yàn)證的工具，在早期利用它來實(shí)現(xiàn)一些功能，多簡(jiǎn)單喲，都不需要自己實(shí)現(xiàn)。

要不是 ZooKeeper 的機(jī)制導(dǎo)致了這個(gè)瓶頸，也不可能會(huì)有這個(gè)改造的。

軟件就是這樣，沒必要重復(fù)造輪子，合適就好。