1、Broker註冊
Broker是分佈式部署並且相互之間相互獨立，但是需要有一個註冊系統能夠將整個集羣中的Broker管理起來；
Broker在zookeeper中保存爲一個臨時節點，節點的路徑是/brokers/ids/[brokerid],每個節點會保存對應broker的IP以及端口等信息；
Kafka的每個broker啓動時，都要先到zookeeper中註冊，因此在整個集羣中，broker.id要求全局唯一；
其中，Broker創建的節點類型是臨時節點，一旦Broker宕機，則對應的臨時節點也會被自動刪除。
全部節點：/brokers/ids
節點路徑：/brokers/ids/{broker.id}
# 打開zk客戶端
cd /usr/local/zookeeper/apache-zookeeper-3.6.1-bin
./bin/zkCli.sh
# 查看註冊的Broker.id
ls /brokers/ids
2、topic的註冊
在Kafka中，同一個Topic的消息會被分成多個分區並將其分佈在多個Broker上，這些分區信息及與Broker的對應關係也都是由Zookeeper在維護，由專門的節點來記錄；
節點路徑：/brokers/topics/{topic_name}
ls /brokers/topics
3、生產者負載均衡
同一個Topic消息會被分區並將其分佈在多個Broker上，因此，生產者需要將消息合理地發送到這些分佈式的Broker上，那麼如何實現生產者的負載均衡，Kafka支持傳統的四層負載均衡，也支持Zookeeper方式實現負載均衡。
(1) 四層負載均衡，根據生產者的IP地址和端口來爲其確定一個相關聯的Broker。通常，一個生產者只會對應單個Broker，然後該生產者產生的消息都發往該Broker。這種方式邏輯簡單，每個生產者不需要同其他系統建立額外的TCP連接，只需要和Broker維護單個TCP連接即可。但是，其無法做到真正的負載均衡，因爲實際系統中的每個生產者產生的消息量及每個Broker的消息存儲量都是不一樣的，如果有些生產者產生的消息遠多於其他生產者的話，那麼會導致不同的Broker接收到的消息總數差異巨大，同時，生產者也無法實時感知到Broker的新增和刪除。
(2) 使用Zookeeper進行負載均衡，由於每個Broker啓動時，都會完成Broker註冊過程，生產者會通過該節點的變化來動態地感知到Broker服務器列表的變更，這樣就可以實現動態的負載均衡機制。
4、消費者負載均衡
與生產者類似，Kafka中的消費者同樣需要進行負載均衡來實現多個消費者合理地從對應的Broker服務器上接收消息，每個消費者分組包含若干消費者，每條消息都只會發送給分組中的一個消費者，不同的消費者分組消費自己特定的Topic下面的消息，互不干擾。
5、消費者與分區的對應關係
對於每個消費者分組，kafka都會爲其分配一個全局唯一的Group ID,分組內的所有消費者會共享該ID,kafka還會爲每個消費者分配一個consumer ID,通常採用hostname:uuid的形式。在kafka的設計中規定，對於topic的每個分區，最多隻能被一個消費者進行消費，也就是消費者與分區的關係是一對多的關係。消費者與分區的關係也被存儲在zookeeper中
路徑：/consumers/[group_id]/owners/[topic]/[broker_id-partition_id]
6、consumer(消費者)在zk中註冊
註冊新的消費者，當有新的消費者註冊到zk中，zk會創建專用的節點來保存相關信息。路徑ls /consumers/{group_id}/ [ids,owners,offset]，Ids:記錄該消費分組有幾個正在消費的消費者，Owmners：記錄該消費分組消費的topic信息，Offset：記錄topic每個分區中的每個offset
監聽消費者分組中消費者的變化 ,監聽/consumers/{group_id}/ids的子節點的變化，一旦發現消費者新增或者減少及時調整消費者的負載均衡
7、消費者的消費進度Offset 記錄
在消費者對指定消息分區進行消息消費的過程中，需要定時地將分區消息的消費進度Offset記錄到Zookeeper上，以便在該消費者進行重啓或者其他消費者重新接管該消息分區的消息消費後，能夠從之前的進度開始繼續進行消息消費。Offset在Zookeeper中由一個專門節點進行記錄。
8、總結
在kafka0.9後的版本，kakfa的broker、topics、消費者等相關信息都存在zk的節點上，並且zk提供了對kafka的動態負載均衡等機制。
0.9版本以前offset存儲在zookeeper，0.9版本以後offset存儲在kafka本地