在曾經(jīng)很長一段時間里，ZooKeeper都是 Kafka的標(biāo)配，現(xiàn)如今，Kafka官方已經(jīng)在慢慢去除ZooKeeper，Kafka 為什么要拋棄 Zookeeper？這篇文章我們來聊聊其中的緣由。

Kafka 和 ZooKeeper 的關(guān)系

ZooKeeper 是一個分布式協(xié)調(diào)服務(wù)，常用于管理配置、命名和同步服務(wù)。長期以來，Kafka 使用 ZooKeeper 負(fù)責(zé)管理集群元數(shù)據(jù)、控制器選舉和消費者組協(xié)調(diào)等任務(wù)理，包括主題、分區(qū)信息、ACL（訪問控制列表）等。

ZooKeeper 為 Kafka 提供了選主（leader election）、集群成員管理等核心功能，為 Kafka提供了一個可靠的分布式協(xié)調(diào)服務(wù)，使得 Kafka能夠在多個節(jié)點之間進(jìn)行有效的通信和管理。然而，隨著 Kafka的發(fā)展，其對 ZooKeeper的依賴逐漸顯露出一些問題，這些問題也是下面 Kafka去除 Zookeeper的原因。

拋棄ZooKeeper的原因

(1) 復(fù)雜性增加

ZooKeeper 是獨立于 Kafka 的外部組件，需要單獨部署和維護(hù)，因此，使用 ZooKeeper 使得 Kafka的運維復(fù)雜度大幅提升。運維團隊必須同時管理兩個分布式系統(tǒng)（Kafka和 ZooKeeper），這不僅增加了管理成本，也要求運維人員具備更高的技術(shù)能力。

(2) 性能瓶頸

作為一個協(xié)調(diào)服務(wù)，ZooKeeper 并非專門為高負(fù)載場景設(shè)計， 因此，隨著集群規(guī)模擴大，ZooKeeper在處理元數(shù)據(jù)時的性能問題日益突出。例如，當(dāng)分區(qū)數(shù)量增加時，ZooKeeper需要存儲更多的信息，這導(dǎo)致了監(jiān)聽延遲增加，從而影響Kafka的整體性能34。在高負(fù)載情況下，ZooKeeper可能成為系統(tǒng)的瓶頸，限制了Kafka的擴展能力。

(3) 一致性問題

Kafka 內(nèi)部的分布式一致性模型與 ZooKeeper 的一致性模型有所不同。由于 ZooKeeper和 Kafka控制器之間的數(shù)據(jù)同步機制不夠高效，可能導(dǎo)致狀態(tài)不一致，特別是在處理集群擴展或不可用情景時，這種不一致性會影響消息傳遞的可靠性和系統(tǒng)穩(wěn)定性。

(4) 發(fā)展自己的生態(tài)

Kafka 拋棄 ZooKeeper，我個人覺得最核心的原因是：Kafka生態(tài)強大了，需要自立門戶，這樣就不會被別人卡脖子。縱觀國內(nèi)外，有很多這樣鮮活的例子，當(dāng)自己弱小時，會先選擇使用別家的產(chǎn)品，當(dāng)自己羽翼豐滿時，再選擇自建完善自己的生態(tài)圈。

引入KRaft

為了剝離和去除 ZooKeeper，Kafka 引入了自己的親兒子 KRaft（Kafka Raft Metadata Mode）。KRaft 是一個新的元數(shù)據(jù)管理架構(gòu)，基于 Raft 一致性算法實現(xiàn)的一種內(nèi)置元數(shù)據(jù)管理方式，旨在替代 ZooKeeper 的元數(shù)據(jù)管理功能。其優(yōu)勢在于：

• 完全內(nèi)置，自包含：KRaft 將所有協(xié)調(diào)服務(wù)嵌入 Kafka 自身，不再依賴外部系統(tǒng)，這樣大大簡化了部署和管理，因為管理員只需關(guān)注 Kafka 集群。
• 高效的一致性協(xié)議：Raft 是一種簡潔且易于理解的一致性算法，易于調(diào)試和實現(xiàn)。KRaft 利用 Raft 協(xié)議實現(xiàn)了強一致性的元數(shù)據(jù)管理，優(yōu)化了復(fù)制機制。
• 提高元數(shù)據(jù)操作的擴展性：新的架構(gòu)允許更多的并發(fā)操作，并減少了因為擴展性問題導(dǎo)致的瓶頸，特別是在高負(fù)載場景中。
• 降低延遲：在消除 ZooKeeper 作為中間層之后，Kafka 的延遲性能有望得到改善，特別是在涉及選主和元數(shù)據(jù)更新的場景中。
• 完全自主：因為是自家產(chǎn)品，所以產(chǎn)品的架構(gòu)設(shè)計，代碼開發(fā)都可以自己說了算，未來架構(gòu)走向完全控制在自己手上。

KRaft的設(shè)計細(xì)節(jié)

控制器（Controller）節(jié)點的去中心化：KRaft 模式中，控制器節(jié)點由一組 Kafka 服務(wù)進(jìn)程代替，而不是一個獨立的 ZooKeeper 集群。這些節(jié)點共同負(fù)責(zé)管理集群的元數(shù)據(jù)，通過 Raft 實現(xiàn)數(shù)據(jù)的一致性。

• 日志復(fù)制和恢復(fù)機制：利用 Raft 的日志復(fù)制和狀態(tài)機應(yīng)用機制，KRaft 實現(xiàn)了對元數(shù)據(jù)變更的強一致性支持，這意味著所有控制器節(jié)點都能夠就集群狀態(tài)達(dá)成共識。
• 動態(tài)集群管理：KRaft 允許動態(tài)地向集群中添加或移除節(jié)點，而無需手動去 ZooKeeper 中更新配置，這使得集群管理更為便捷。

下面給出一張 Zookeeper 和 KRaft的對比圖：

總結(jié)

本文，我們分析了為什么 Kafka 要移除 ZooKeeper，主要原因有兩個：ZooKeeper不能滿足 Kafka的發(fā)展以及 Kafka想創(chuàng)建自己的生態(tài)。在面臨越來越復(fù)雜的數(shù)據(jù)流處理需求時，KRaft 模式為 Kafka 提供了一種更高效、簡潔的架構(gòu)方案。不論結(jié)局如何，Kafka 和 ZooKeeper曾經(jīng)也度過了一段美好的蜜月期，祝福 Kafka 在 KRaft模式越來越強大，為使用者帶來更好的體驗。