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

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

其實去年我寫的 Kafka 控制器事件處理全流程這篇文章已經提到這一點。

今天再稍微展開來說說。

ZooKeeper 的作用

ZooKeeper 是一個開源的分布式協調服務框架，你也可以認為它是一個可以保證一致性的分布式(小量)存儲系統(tǒng)。特別適合存儲一些公共的配置信息、集群的一些元數據等等。

它有持久節(jié)點和臨時節(jié)點，而臨時節(jié)點這個玩意再配合 Watcher 機制就很有用。

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

所以集群中某一服務上線或者下線，都可以被檢測到。因此可以用來實現服務發(fā)現，也可以實現故障轉移的監(jiān)聽機制。

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

在每個 Broker 啟動的時候，都會和 ZooKeeper 進行交互，這樣 ZooKeeper 就存儲了集群中所有的主題、配置、副本等信息。

還有一些選舉、擴容等機制也都依賴 ZooKeeper 。

例如控制器的選舉：每個 Broker 啟動都會嘗試在 ZooKeeper 注冊/controller臨時節(jié)點來競選控制器，第一個創(chuàng)建/controller節(jié)點的 Broker 會被指定為控制器。

競爭失敗的節(jié)點也會依賴 watcher 機制，監(jiān)聽這個節(jié)點，如果控制器宕機了，那么其它 Broker 會繼續(xù)來爭搶，實現控制器的 failover。

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

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

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

那為什么要拋棄 ZooKeeper

軟件架構都是演進的，之所以要變更那肯定是因為出現了瓶頸。

先來看看運維的層面的問題。

首先身為一個中間件，需要依賴另一個中間件，這就感覺有點奇怪。

你要說依賴 Netty 這種，那肯定是沒問題的。但是 Kafka 的運行需要提供 ZooKeeper 集群，這其實有點怪怪的。

就等于如果你公司要上 Kafka 就得跟著上 ZooKeeper ，被動了增加了運維的復雜度。

好比你去商場買衣服，要買個上衣，服務員說不單賣，要買就得買一套，這錢是不是多花了？

所以運維人員不僅得照顧 Kafka 集群，還得照顧 ZooKeeper 集群。

再看性能層面的問題。

ZooKeeper 有個特點，強一致性 。

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

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

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

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

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

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

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

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

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

所以，Kafka 需要去 ZooKeeper 。

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

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

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

沒了 Zookeeper 的 Kafka 就把元數據存儲到自己內部了，利用之前的 Log 存儲機制來保存元數據。

就和上面說到的位移主題一樣，會有一個元數據主題，元數據會像普通消息一樣保存在 Log 中。

所以元數據和之前的位移一樣，利用現有的消息存儲機制稍加改造來實現了功能，完美！

然后還搞了個 KRaft 來實現 Controller Quorum。

圖來自 confluent

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

在之前基于 Zookeeper 實現的單個 Controller 在分區(qū)數太大的時候還有個問題，故障轉移太慢了。

當 Controller 變更的時候，需要重新加載所有的元數據到新的 Controller 身上，并且需要把這些元數據同步給集群內的所有 Broker。

而 Controller Quorum 中的 Leader 選舉切換則很快，因為元數據都已經在 quorum 中同步了，也就是 quorum 的 Broker 都已經有全部了元數據，所以不需要重新加載元數據！

并且其它 Broker 已經基于 Log 存儲了一些元數據，所以只需要增量更新即可，不需要全量了。

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

最后

可能看到這里有人會說，那為何一開始不這么實現？

因為 ZooKeeper 是一個功能強大且經過驗證的工具，在早期利用它來實現一些功能，多簡單喲，都不需要自己實現。

要不是 ZooKeeper 的機制導致了這個瓶頸，也不可能會有這個改造的。

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