在上個月 30 號， confluent 發布了一篇文章，文章上說在 Kafka 2.8 版本上將支持內部的 quorum 服務來替換 ZooKeeper 的作業，
ZooKeeper 的作用
ZooKeeper 是一個開源的分布式協調服務框架，你也可以認為它是一個可以保證一致性的分布式(小量)存盤系統，特別適合存盤一些公共的配置資訊、集群的一些元資料等等，
它有持久節點和臨時節點，而臨時節點這個玩意再配合 Watcher 機制就很有用，
當創建臨時節點的客戶端與 ZooKeeper 斷連之后，這個臨時節點就會消失，并且訂閱了節點狀態變更的客戶端會收到這個節點狀態變更的通知，
所以集群中某一服務上線或者下線，都可以被檢測到，因此可以用來實作服務發現，也可以實作故障轉移的監聽機制，
Kafka 就是強依賴于 ZooKeeper，沒有 ZooKeeper 的話 Kafka 都無法運行，ZooKeeper 為 Kafka 提供了元資料的管理，例如一些 Broker 的資訊、主題資料、磁區資料等等，
在每個 Broker 啟動的時候，都會和 ZooKeeper 進行互動，這樣 ZooKeeper 就存盤了集群中所有的主題、配置、副本等資訊，
還有一些選舉、擴容等機制也都依賴 ZooKeeper ，
例如控制器的選舉：每個 Broker 啟動都會嘗試在 ZooKeeper 注冊/controller臨時節點來競選控制器，第一個創建/controller節點的 Broker 會被指定為控制器，
競爭失敗的節點也會依賴 watcher 機制，監聽這個節點，如果控制器宕機了，那么其它 Broker 會繼續來爭搶，實作控制器的 failover，
從上面就可以得知 ZooKeeper 對 Kafka 來說很重要，
那為什么要拋棄 ZooKeeper
軟體架構都是演進的，之所以要變更那肯定是因為出現了瓶頸，
先來看看運維的層面的問題，
首先身為一個中間件，需要依賴另一個中間件，這就感覺有點奇怪，
你要說依賴 Netty 這種，那肯定是沒問題的，但是 Kafka 的運行需要提供 ZooKeeper 集群，這其實有點怪怪的，
就等于如果你公司要上 Kafka 就得跟著上 ZooKeeper ，被動了增加了運維的復雜度，
好比你去商場買衣服，要買個上衣，服務員說不單賣，要買就得買一套，這錢是不是多花了？
所以運維人員不僅得照顧 Kafka 集群，還得照顧 ZooKeeper 集群，
再看性能層面的問題，
ZooKeeper 有個特點，強一致性，
如果 ZooKeeper 集群的某個節點的資料發生變更，則會通知其它 ZooKeeper 節點同時執行更新，就得等著大家（超過半數）都寫完了才行，這寫入的性能就比較差了，
然后看到上面我說的小量存盤系統了吧，一般而言，ZooKeeper 只適用于存盤一些簡單的配置或者是集群的元資料，不是真正意義上的存盤系統，
如果寫入的資料量過大，ZooKeeper 的性能和穩定性就會下降，可能導致 Watch 的延時或丟失，
所以在 Kafka 集群比較大，磁區數很多的時候，ZooKeeper 存盤的元資料就會很多，性能就差了，
還有，ZooKeeper 也是分布式的，也需要選舉，它的選舉也不快，而且發生選舉的那段時候是不提供服務的！
基于 ZooKeeper 的性能問題 Kafka 之前就做了一些升級，
例如以前 Consumer 的位移資料是保存在 ZooKeeper 上的，所以當提交位移或者獲取位移的時候都需要訪問 ZooKeeper ，這量一大 ZooKeeper 就頂不住，
所以后面引入了位移主題（Topic 是 __consumer_offsets），將位移的提交和獲取當做訊息一樣來處理，存盤在日志中，避免了頻繁訪問 ZooKeeper 性能差的問題，
還有像一些大公司，可能要支持百萬磁區級別，這目前的 Kafka 單集群架構下是無法支持穩定運行的，也就是目前單集群可以承載的磁區數有限，
所以，Kafka 需要去 ZooKeeper ，
所以沒了 Zookeeper 之后的 Kafka 的怎樣的？
沒了 Zookeeper 的 Kafka 就把元資料存盤到自己內部了，利用之前的 Log 存盤機制來保存元資料，
就和上面說到的位移主題一樣，會有一個元資料主題，元資料會像普通訊息一樣保存在 Log 中，
所以元資料和之前的位移一樣，利用現有的訊息存盤機制稍加改造來實作了功能，完美！
然后還搞了個 KRaft 來實作 Controller Quorum，
圖來自 confluent
這個協議是基于 Raft 的，協議具體就不展開了，就理解為它能解決 Controller Leader 的選舉，并且讓所有節點達成共識，
在之前基于 Zookeeper 實作的單個 Controller 在磁區數太大的時候還有個問題，故障轉移太慢了，
當 Controller 變更的時候，需要重新加載所有的元資料到新的 Controller 身上，并且需要把這些元資料同步給集群內的所有 Broker，
而 Controller Quorum 中的 Leader 選舉切換則很快，因為元資料都已經在 quorum 中同步了，也就是 quorum 的 Broker 都已經有全部了元資料，所以不需要重新加載元資料！
并且其它 Broker 已經基于 Log 存盤了一些元資料，所以只需要增量更新即可，不需要全量了，
這波改造下來就解決了之前元資料過多的問題，可以支持更多的磁區！
最后
可能看到這里有人會說，那為何一開始不這么實作？
因為 ZooKeeper 是一個功能強大且經過驗證的工具，在早期利用它來實作一些功能，多簡單喲，都不需要自己實作，
要不是 ZooKeeper 的機制導致了這個瓶頸，也不可能會有這個改造的，
軟體就是這樣，沒必要重復造輪子，合適就好，
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/283078.html
標籤：其他