1糖权、Broker注冊
Broker是分布式部署并且相互之間相互獨立堵腹，但是需要有一個注冊系統(tǒng)能夠?qū)⒄麄€集群中的Broker管理起來，此時就使用到了Zookeeper星澳。在Zookeeper上會有一個專門用來進行Broker服務器列表記錄的節(jié)點：
/brokers/ids
每個Broker在啟動時疚顷，都會到Zookeeper上進行注冊，即到/brokers/ids下創(chuàng)建屬于自己的節(jié)點禁偎，如/brokers/ids/[0...N]腿堤。
Kafka使用了全局唯一的數(shù)字來指代每個Broker服務器，不同的Broker必須使用不同的Broker ID進行注冊如暖，創(chuàng)建完節(jié)點后笆檀，每個Broker就會將自己的IP地址和端口信息記錄到該節(jié)點中去。其中盒至，Broker創(chuàng)建的節(jié)點類型是臨時節(jié)點酗洒，一旦Broker宕機士修，則對應的臨時節(jié)點也會被自動刪除。
2樱衷、Topic注冊
在Kafka中棋嘲，同一個Topic的消息會被分成多個分區(qū)并將其分布在多個Broker上，這些分區(qū)信息及與Broker的對應關系也都是由Zookeeper在維護箫老，由專門的節(jié)點來記錄封字，如：
/borkers/topics
Kafka中每個Topic都會以/brokers/topics/[topic]的形式被記錄黔州，如/brokers/topics/login和/brokers/topics/search等耍鬓。Broker服務器啟動后，會到對應Topic節(jié)點（/brokers/topics）上注冊自己的Broker ID并寫入針對該Topic的分區(qū)總數(shù)流妻，如/brokers/topics/login/3->2牲蜀，這個節(jié)點表示Broker ID為3的一個Broker服務器，對于"login"這個Topic的消息绅这，提供了2個分區(qū)進行消息存儲涣达，同樣，這個分區(qū)節(jié)點也是臨時節(jié)點证薇。
3度苔、生產(chǎn)者負載均衡
由于同一個Topic消息會被分區(qū)并將其分布在多個Broker上，因此浑度，生產(chǎn)者需要將消息合理地發(fā)送到這些分布式的Broker上寇窑，那么如何實現(xiàn)生產(chǎn)者的負載均衡，Kafka支持傳統(tǒng)的四層負載均衡箩张，也支持Zookeeper方式實現(xiàn)負載均衡甩骏。
(1) 四層負載均衡，根據(jù)生產(chǎn)者的IP地址和端口來為其確定一個相關聯(lián)的Broker先慷。通常饮笛，一個生產(chǎn)者只會對應單個Broker，然后該生產(chǎn)者產(chǎn)生的消息都發(fā)往該Broker论熙。這種方式邏輯簡單福青，每個生產(chǎn)者不需要同其他系統(tǒng)建立額外的TCP連接，只需要和Broker維護單個TCP連接即可脓诡。但是素跺，其無法做到真正的負載均衡，因為實際系統(tǒng)中的每個生產(chǎn)者產(chǎn)生的消息量及每個Broker的消息存儲量都是不一樣的誉券，如果有些生產(chǎn)者產(chǎn)生的消息遠多于其他生產(chǎn)者的話指厌，那么會導致不同的Broker接收到的消息總數(shù)差異巨大，同時踊跟，生產(chǎn)者也無法實時感知到Broker的新增和刪除踩验。
(2) 使用Zookeeper進行負載均衡鸥诽，由于每個Broker啟動時，都會完成Broker注冊過程箕憾，生產(chǎn)者會通過該節(jié)點的變化來動態(tài)地感知到Broker服務器列表的變更牡借，這樣就可以實現(xiàn)動態(tài)的負載均衡機制。
4袭异、消費者負載均衡
與生產(chǎn)者類似钠龙，Kafka中的消費者同樣需要進行負載均衡來實現(xiàn)多個消費者合理地從對應的Broker服務器上接收消息，每個消費者分組包含若干消費者御铃，每條消息都只會發(fā)送給分組中的一個消費者碴里，不同的消費者分組消費自己特定的Topic下面的消息，互不干擾上真。
5咬腋、消費分區(qū)與消費者的關系
對于每個消費者分組，Kafka都會為其分配一個全局唯一的Group ID睡互，同一個消費者分組內(nèi)部的所有消費者共享該ID根竿。同時，Kafka為每個消費者分配一個Consumer ID就珠，通常采用"Hostname:UUID"形式表示寇壳。在Kafka中，規(guī)定了每個消息分區(qū)有且只能同時有一個消費者進行消費妻怎，因此壳炎，需要在Zookeeper上記錄消息分區(qū)與消費者之間的關系，每個消費者一旦確定了對一個消息分區(qū)的消費權(quán)力蹂季，需要將其Consumer ID 寫入到對應消息分區(qū)的臨時節(jié)點上冕广，例如：
/consumers/[group_id]/owners/[topic]/[broker_id-partition_id]
其中，[broker_id-partition_id]就是一個消息分區(qū)的標識偿洁，節(jié)點內(nèi)容就是該消費分區(qū)上消息消費者的Consumer ID撒汉。
6、消息消費進度Offset記錄
在消費者對指定消息分區(qū)進行消息消費的過程中涕滋，需要定時地將分區(qū)消息的消費進度Offset記錄到Zookeeper上睬辐，以便在該消費者進行重啟或者其他消費者重新接管該消息分區(qū)的消息消費后，能夠從之前的進度開始繼續(xù)進行消息消費宾肺。Offset在Zookeeper中由一個專門節(jié)點進行記錄溯饵，其節(jié)點路徑為:
/consumers/[group_id]/offsets/[topic]/[broker_id-partition_id]
節(jié)點內(nèi)容就是Offset的值。
7锨用、消費者注冊
消費者服務器在初始化啟動時加入消費者分組的步驟如下
- 注冊到消費者分組丰刊。每個消費者服務器啟動時，都會到Zookeeper的指定節(jié)點下創(chuàng)建一個屬于自己的消費者節(jié)點增拥，例如/consumers/[group_id]/ids/[consumer_id]啄巧，完成節(jié)點創(chuàng)建后寻歧，消費者就會將自己訂閱的Topic信息寫入該臨時節(jié)點。
- 對消費者分組中的消費者的變化注冊監(jiān)聽秩仆。每個消費者都需要關注所屬消費者分組中其他消費者服務器的變化情況码泛，即對/consumers/[group_id]/ids節(jié)點注冊子節(jié)點變化的Watcher監(jiān)聽，一旦發(fā)現(xiàn)消費者新增或減少澄耍，就觸發(fā)消費者的負載均衡噪珊。
- 對Broker服務器變化注冊監(jiān)聽。消費者需要對/broker/ids/[0-N]中的節(jié)點進行監(jiān)聽齐莲，如果發(fā)現(xiàn)Broker服務器列表發(fā)生變化痢站，那么就根據(jù)具體情況來決定是否需要進行消費者負載均衡。
- 進行消費者負載均衡铅搓。為了讓同一個Topic下不同分區(qū)的消息盡量均衡地被多個消費者消費而進行消費者與消息分區(qū)分配的過程瑟押，通常搀捷，對于一個消費者分組星掰，如果組內(nèi)的消費者服務器發(fā)生變更或Broker服務器發(fā)生變更，會發(fā)出消費者負載均衡嫩舟。
以下是kafka在zookeep中的詳細存儲結(jié)構(gòu)圖：
