一、ZooKeeper 的核心功能
ZooKeeper 是一個(gè)廣泛使用的開源分布式協(xié)調(diào)服務(wù)框架，它在確保數(shù)據(jù)一致性方面表現(xiàn)出色，同時(shí)也可以作為一個(gè)輕量級的分布式存儲系統(tǒng)。它特別適合用來存儲那些需要多個(gè)系統(tǒng)共享的配置信息、集群的元數(shù)據(jù)等。ZooKeeper 提供了持久節(jié)點(diǎn)和臨時(shí)節(jié)點(diǎn)兩種類型，其中臨時(shí)節(jié)點(diǎn)的功能在結(jié)合了 Watcher 機(jī)制后顯得尤為強(qiáng)大。當(dāng)一個(gè)客戶端與 ZooKeeper 的連接斷開，它所創(chuàng)建的臨時(shí)節(jié)點(diǎn)將會自動(dòng)刪除，同時(shí)，那些訂閱了節(jié)點(diǎn)狀態(tài)變更通知的客戶端將會及時(shí)接收到相關(guān)通知。這種機(jī)制使得 ZooKeeper 在處理分布式系統(tǒng)中的協(xié)調(diào)任務(wù)時(shí)非常高效。

因此，ZooKeeper 能夠偵測到集群中任何服務(wù)的啟動(dòng)或關(guān)閉，這使得它成為實(shí)現(xiàn)服務(wù)發(fā)現(xiàn)和故障轉(zhuǎn)移監(jiān)聽機(jī)制的理想選擇。Kafka 便是一個(gè)依賴于 ZooKeeper 的典型例子，沒有 ZooKeeper 的支持，Kafka 將無法正常運(yùn)作。ZooKeeper 為 Kafka 提供了元數(shù)據(jù)管理的功能，包括但不限于 Broker 的信息、主題數(shù)據(jù)、分區(qū)數(shù)據(jù)等。每當(dāng) Kafka 的 Broker 啟動(dòng)時(shí)，它都會與 ZooKeeper 進(jìn)行通信，確保 ZooKeeper 能夠維護(hù)集群中所有主題、配置和副本等關(guān)鍵信息。

ZooKeeper 還承擔(dān)著諸如選舉和擴(kuò)容等重要機(jī)制的功能。例如，在控制器選舉過程中，每個(gè) Kafka Broker 啟動(dòng)時(shí)都會嘗試在 ZooKeeper 中注冊一個(gè)臨時(shí)的 “/controller” 節(jié)點(diǎn)以參與競選，首先成功創(chuàng)建該節(jié)點(diǎn)的 Broker 將被選為控制器。其他競爭失敗的節(jié)點(diǎn)則會通過 Watcher 機(jī)制監(jiān)控這個(gè)節(jié)點(diǎn)，一旦控制器發(fā)生故障，其他 Broker 將繼續(xù)進(jìn)行競選，從而實(shí)現(xiàn)控制器的故障轉(zhuǎn)移。這進(jìn)一步凸顯了 ZooKeeper 對 Kafka 的重要性。
二、為何要放棄 ZooKeeper
軟件架構(gòu)隨著時(shí)間不斷演進(jìn)，當(dāng)出現(xiàn)瓶頸時(shí)，變革便成為了必然。以下是一些放棄 ZooKeeper 的原因：
2.1、運(yùn)維層面的問題
首先，作為一個(gè)中間件，Kafka 卻需要依賴于另一個(gè)中間件 ZooKeeper，這種設(shè)計(jì)在某種程度上顯得不太合理。雖然依賴如 Netty 這樣的網(wǎng)絡(luò)框架是可以理解的，但 Kafka 需要運(yùn)行在 ZooKeeper 集群之上，這顯得有些不協(xié)調(diào)。這就意味著，如果公司想要部署 Kafka，就必須同時(shí)部署 ZooKeeper，這無疑增加了運(yùn)維的復(fù)雜性。因此，運(yùn)維人員不僅要管理 Kafka 集群，還要管理 ZooKeeper 集群。
2.2、性能層面的問題
ZooKeeper 強(qiáng)調(diào)一致性，當(dāng)一個(gè)節(jié)點(diǎn)上的數(shù)據(jù)發(fā)生變化時(shí)，其他節(jié)點(diǎn)必須等待通知并同步更新，這要求所有節(jié)點(diǎn)（超過半數(shù)）完成寫入后才能繼續(xù)，這種機(jī)制在寫入性能上存在瓶頸。

如您所見，ZooKeeper 被描述為一個(gè)適用于存儲簡單配置或集群元數(shù)據(jù)的小量存儲系統(tǒng)，它并不是一個(gè)傳統(tǒng)意義上的存儲系統(tǒng)。當(dāng)處理大量寫入數(shù)據(jù)時(shí)，ZooKeeper 的性能和穩(wěn)定性可能會受到影響，導(dǎo)致 Watch 通知的延遲或丟失。特別是在 Kafka 集群規(guī)模較大、分區(qū)數(shù)量眾多的情況下，ZooKeeper 存儲的元數(shù)據(jù)量會增加，其性能就會顯得不足。此外，ZooKeeper 作為分布式系統(tǒng)，也需要進(jìn)行選舉，而選舉過程不僅緩慢，還會在選舉期間導(dǎo)致服務(wù)不可用。

2.3、針對 ZooKeeper 的性能問題，Kafka 已經(jīng)進(jìn)行了一些改進(jìn)。例如，以前消費(fèi)者的位移數(shù)據(jù)存儲在 ZooKeeper 上，提交位移或獲取位移時(shí)都需要訪問 ZooKeeper，這在數(shù)據(jù)量大時(shí)會導(dǎo)致 ZooKeeper 承受不住。為此，Kafka 引入了位移主題（如 “__consumer_offsets”），將位移的提交和獲取作為消息處理，存儲在日志中，從而避免了頻繁訪問 ZooKeeper 的性能問題。對于一些需要支持百萬級別分區(qū)的大公司來說，當(dāng)前 Kafka 單集群架構(gòu)下無法穩(wěn)定運(yùn)行，即單集群支持的分區(qū)數(shù)量有限。因此，Kafka 需要擺脫對 ZooKeeper 的依賴。

2.4、那么，沒有了 ZooKeeper 的 Kafka 會是什么樣子呢？沒有了 ZooKeeper 的 Kafka 將元數(shù)據(jù)存儲移至內(nèi)部，利用現(xiàn)有的日志存儲機(jī)制來保存元數(shù)據(jù)。就像之前提到的位移主題一樣，會有一個(gè)專門的元數(shù)據(jù)主題，元數(shù)據(jù)就像普通消息一樣存儲在日志中。因此，元數(shù)據(jù)的存儲和之前的位移存儲一樣，通過現(xiàn)有的消息存儲機(jī)制進(jìn)行了一些改造，實(shí)現(xiàn)了所需功能，非常巧妙！此外，Kafka 還引入了 KRaft 模式來實(shí)現(xiàn)控制器的一致性。

這個(gè)協(xié)議是基于 Raft 算法的，具體的協(xié)議細(xì)節(jié)這里就不展開了，你只需要知道它能夠有效地解決控制器領(lǐng)導(dǎo)者的選舉問題，并確保集群內(nèi)所有節(jié)點(diǎn)達(dá)成一致。
在以前依賴 ZooKeeper 實(shí)現(xiàn)的單控制器模式中，當(dāng)分區(qū)數(shù)量巨大時(shí)，故障轉(zhuǎn)移的過程往往非常緩慢。

這是因?yàn)楫?dāng)控制器發(fā)生變更時(shí)，需要將所有元數(shù)據(jù)重新加載到新的控制器上，并且將這些元數(shù)據(jù)同步給集群中的所有 Kafka Broker。
而在控制器集群（Controller Quorum）中，領(lǐng)導(dǎo)者的選舉和切換過程就快得多，因?yàn)樵獢?shù)據(jù)已經(jīng)在集群中同步，即集群中的所有 Broker 都已經(jīng)擁有完整的元數(shù)據(jù)，無需重新加載。
此外，其他 Broker 已經(jīng)基于日志存儲了部分元數(shù)據(jù)，因此只需進(jìn)行增量更新，而不需要全量更新。
通過這樣的改進(jìn)，就解決了之前由于元數(shù)據(jù)過多而無法支持更多分區(qū)的問題。

三、結(jié)語
可能會有讀者思考，為什么一開始不直接采用這樣的實(shí)現(xiàn)方式呢？
這是因?yàn)?ZooKeeper 是一個(gè)功能強(qiáng)大且經(jīng)過實(shí)踐驗(yàn)證的工具，早期使用它來實(shí)現(xiàn)某些功能是非常簡單的，無需從頭開始自己實(shí)現(xiàn)。
如果不是因?yàn)?ZooKeeper 的機(jī)制遇到了性能瓶頸，這樣的改造可能永遠(yuǎn)不會發(fā)生。
軟件開發(fā)就是這樣，沒有必要重復(fù)造輪子，找到合適的工具和解決方案才是關(guān)鍵。

AigcFox工具箱--主流自媒體平臺視頻、圖文內(nèi)容一鍵發(fā)布。視頻、圖片自動(dòng)裂變n份并去重。多賬號自動(dòng)發(fā)布，模擬人工操作，無人值守。賬戶綁定上網(wǎng)卡或手機(jī)共享網(wǎng)絡(luò)，可實(shí)現(xiàn)發(fā)布IP隔離。AI內(nèi)容：可對文章、圖片改寫、潤色、增強(qiáng)。文章來源地址http://www.zghlxwxcb.cn/news/detail-787845.html

到了這里，關(guān)于Kafka 的未來：為何我們要拋棄 ZooKeeper？的文章就介紹完了。如果您還想了解更多內(nèi)容，請?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！