以下是kafka在zookeep中的詳細存儲結構圖：

?

1.Broker注冊

Kafka是一個分布式的消息系統。Kafka 集群包含一個或多個服務器，服務器節點稱為broker。雖然Broker是分布式部署并且相互之間獨立運行的，但是還需要一個注冊系統能夠將整個集群中的Broker服務器都管理起來。

在ZooKeeper上有一個專門用來進行Broker服務器列表記錄的節點，下文中我們稱之為“Broker節點”，其節點路徑為/brokers/ids。

每個Broker服務器在啟動時，都會到ZooKeeper上進行注冊，即到Broker節點下創建屬于自己的節點，其節點路徑為/broker/ids/[0...N]。

從上面的節點路徑中，我們可以看出，在Kafka中，我們使用一個全局唯一的數字來指定每一個Broker服務器，可以稱其為“Broker ID"。不同的Broker必須使用不同的Broker ID進行注冊。

注意：Broker創建的節點是一個臨時節點，也就是說，一旦這個Broker服務器宕機或下線后，那么對應的Broker節點也就被刪除了。

2.Topic注冊

在Kafka中，會將同一個Topic的消息分成多個分區并將其分布到多個Broker上，這些信息在ZooKeeper上由專門的節點來記錄，其節點路徑為/brokers/topics。Kafka中的每一個Topic，都會以/brokers/topics/[topic]的形式記錄在這個節點下，例如/brokers/topic/login和/brokers/topics/search等。

Broker服務器在啟動后，會到對應的Topic節點下注冊自己的Broker ID，并寫入針對該Topic的分區總數。

例如，/brokers/topics/login/3 -->2 這個節點表明Broker ID為3的一個Broker服務器，對于“login”這個topic的消息，提供了2個分區進行消息存儲。同樣，這個分區數節點也是一個臨時節點。

3.生產者負載均衡

由于同一個Topic消息會被分區并將其分布在多個Broker上，因此，生產者需要將消息合理地發送到這些分布式的Broker上，那么如何實現生產者的負載均衡，Kafka支持傳統的四層負載均衡，也支持Zookeeper方式實現負載均衡。

(1) 四層負載均衡，根據生產者的IP地址和端口來為其確定一個相關聯的Broker。通常，一個生產者只會對應單個Broker，然后該生產者產生的消息都發往該Broker。這種方式邏輯簡單，每個生產者不需要同其他系統建立額外的TCP連接，只需要和Broker維護單個TCP連接即可。但是，其無法做到真正的負載均衡，因為實際系統中的每個生產者產生的消息量及每個Broker的消息存儲量都是不一樣的，如果有些生產者產生的消息遠多于其他生產者的話，那么會導致不同的Broker接收到的消息總數差異巨大，同時，生產者也無法實時感知到Broker的新增和刪除。

(2) 使用Zookeeper進行負載均衡，由于每個Broker啟動時，都會完成Broker注冊過程，生產者會注冊Broker節點的Watcher事件監聽，通過該節點的變化來動態地感知到Broker服務器列表的變更，這樣就可以實現動態的負載均衡機制。

4.消費者負載均衡

與生產者類似，Kafka中的消費者同樣需要進行負載均衡來實現多個消費者合理的從對應的Broker服務器上接收消息。Kafka有消費者分組的概念，每個消費者分組中都包含了若干個消費者，每一條消息都只會發送給分組中的一個消費者，不同的消費者分組消費自己特定Topic下面的消息，互不干擾。因此消費者的負載均衡也可以看作是同一個消費者分組內部的消息消費策略。

5.消息消費進度Offset 記錄

在消費者對指定消息分區進行消息消費的過程中，需要定時地將分區消息的消費進度Offset記錄到Zookeeper上，以便在該消費者進行重啟或者其他消費者重新接管該消息分區的消息消費后，能夠從之前的進度開始繼續進行消息消費。Offset在Zookeeper中由一個專門節點進行記錄，其節點路徑為:

/consumers/[group_id]/offsets/[topic]/[broker_id-partition_id]

節點內容就是Offset的值。

6.消費者注冊

消費者服務器在初始化啟動時加入消費者分組的步驟如下:

1）注冊到消費者分組

每個消費者服務器啟動時，都會到Zookeeper的指定節點下創建一個屬于自己的消費者節點，例如/consumers/[group_id]/ids/[consumer_id]，完成節點創建后，消費者就會將自己訂閱的Topic信息寫入該臨時節點。

2）對消費者分組中的消費者的變化注冊監聽

每個消費者都需要關注所屬消費者分組中其他消費者服務器的變化情況，即對/consumers/[group_id]/ids節點注冊子節點變化的Watcher監聽，一旦發現消費者新增或減少，就觸發消費者的負載均衡。

3）對Broker服務器變化注冊監聽

消費者需要對/broker/ids/[0-N]中的節點進行監聽，如果發現Broker服務器列表發生變化，那么就根據具體情況來決定是否需要進行消費者負載均衡。

4）進行消費者負載均衡。

為了讓同一個Topic下不同分區的消息盡量均衡地被多個消費者消費而進行消費者與消息分區分配的過程，通常，對于一個消費者分組，如果組內的消費者服務器發生變更或Broker服務器發生變更，會發出消費者負載均衡。

6.補充

早期版本的 kafka 用 ZooKeeper 做 meta 信息存儲、consumer 的消費狀態、group 的管理以及offset的值。考慮到ZooKeeper本身的一些因素以及整個架構較大概率存在單點問題，新版本中確實逐漸弱化了ZooKeeper的作用。新的consumer使用了kafka內部的group coordination協議，也減少了對ZooKeeper的依賴。

Kafka 0.9版本之后，consumer已經不通過ZooKeeper來實現重平衡。而是使用GroupCoordinator機制。

Coordinator具體介紹可以查看博客：https://www.cnblogs.com/zhy-heaven/p/10994022.html

?

?

總結

以上是生活随笔為你收集整理的Kafka在ZooKeeper中的应用的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。