基礎總結：
1）broker :broker代表kafka的節點， Broker是分布式部署並且相互之間相互獨立的， 啟動的時候向zookeeper 註冊，在Zookeeper上會有壹個專門 用來進行Broker服務器列表記錄 的節點：/brokers/ids。每個Broker在啟動時，都會到Zookeeper上進行註冊，即到/brokers/ids下創建屬於自己的節點，如/brokers/ids/[0...N]。Kafka使用了全局唯壹的數字來指代每個Broker服務器，不同的Broker必須使用不同的Broker ID進行註冊，創建完節點後， 每個Broker就會將自己的IP地址和端口信息記錄 到該節點中去。其中，Broker創建的節點類型是 臨時節點 ，壹旦Broker 宕機 ，則 對應的臨時節點也會被自動刪除 。
2）topic：消息主題，在Kafka中，同壹個 Topic的消息會被分成多個分區 並將其分布在多個Broker上， 這些分區信息及與Broker的對應關系 也都是由Zookeeper在維護，由專門的節點來記錄，如：/borkers/topics Kafka中每個Topic都會以/brokers/topics/[topic]的形式被記錄，如/brokers/topics/login和/brokers/topics/search等。Broker服務器啟動後，會到對應Topic節點（/brokers/topics）上註冊自己的Broker ID並寫入針對該Topic的分區總數，如/brokers/topics/login/3->2，這個節點表示Broker ID為3的壹個Broker服務器，對於"login"這個Topic的消息，提供了2個分區進行消息存儲，同樣，這個分區節點也是臨時節點。
3）partition ：同壹topic類型消息的分區，如圖，每個分區都存在壹個leader 和N個follower（副本），副本個數在創建topic的時候可以指定創建多少個。消息生產者生產消息和消費組消費消息都是通過leader完成，副本的存在是為了防止發生節點宕機，導致leader掛了，follower隨時頂上去變成leader，繼續恢復生產。重點來了，leader所在節點掛了，會有follower變成leader，所以同壹個topic的同壹個partition的leader與follower不可能在同壹個broker，這樣才能做到這個broker上的某個topic的某個partition的leader掛了，其他正常節點上的這個topic的這個partition的follower會頂上來。
4）生產者發送消息的 負載均衡 ：由於同壹個Topic消息會被分區並將其分布在多個Broker上，因此， 生產者需要將消息合理地發送到這些分布式的Broker上 ，那麽如何實現生產者的負載均衡，Kafka支持傳統的四層負載均衡，也支持Zookeeper方式實現負載均衡。 (4.1) 四層負載均衡，根據生產者的IP地址和端口來為其確定壹個相關聯的Broker。通常，壹個生產者只會對應單個Broker，然後該生產者產生的消息都發往該Broker。這種方式邏輯簡單，每個生產者不需要同其他系統建立額外的TCP連接，只需要和Broker維護單個TCP連接即可。但是，其無法做到真正的負載均衡，因為實際系統中的每個生產者產生的消息量及每個Broker的消息存儲量都是不壹樣的，如果有些生產者產生的消息遠多於其他生產者的話，那麽會導致不同的Broker接收到的消息總數差異巨大，同時，生產者也無法實時感知到Broker的新增和刪除。 (4.2) 使用Zookeeper進行負載均衡，由於每個Broker啟動時，都會完成Broker註冊過程，生產者會通過該節點的變化來動態地感知到Broker服務器列表的變更，這樣就可以實現動態的負載均衡機制。
5）消費者負載均衡：與生產者類似，Kafka中的消費者同樣需要進行負載均衡來實現多個消費者合理地從對應的Broker服務器上接收消息，每個消費組分組包含若幹消費者， 每條消息都只會發送給分組中的壹個消費者 ，不同的消費者分組消費自己特定的Topic下面的消息，互不幹擾。
6）分區與消費者 的關系： 消費組 (Consumer Group)? consumer group 下有多個 Consumer（消費者）。對於每個消費者組 (Consumer Group)，Kafka都會為其分配壹個全局唯壹的Group ID，Group 內部的所有消費者***享該 ID。訂閱的topic下的每個分區只能分配給某個 group 下的壹個consumer(當然該分區還可以被分配給其他group)。同時，Kafka為每個消費者分配壹個Consumer ID，通常采用"Hostname:UUID"形式表示。在Kafka中，規定了 每個消息分區 只能被同組的壹個消費者進行消費 ，因此，需要在 Zookeeper 上記錄 消息分區 與 Consumer 之間的關系，每個消費者壹旦確定了對壹個消息分區的消費權力，需要將其Consumer ID 寫入到 Zookeeper 對應消息分區的臨時節點上，例如：/consumers/[group_id]/owners/[topic]/[broker_id-partition_id]? 其中，[broker_id-partition_id]就是壹個 消息分區 的標識，節點內容就是該 消息分區 上 消費者的Consumer ID。
7）消息的消費進度Offset 記錄：在消費者對指定消息分區進行消息消費的過程中， 需要定時地將分區消息的消費進度Offset記錄到Zookeeper上 ，以便在該消費者進行重啟或者其他消費者重新接管該消息分區的消息消費後，能夠從之前的進度開始繼續進行消息消費。Offset在Zookeeper中由壹個專門節點進行記錄，其節點路徑為:/consumers/[group_id]/offsets/[topic]/[broker_id-partition_id] 節點內容就是Offset的值。這是kafka0.9和之前版本offset記錄的方式，之後的版本offset都改為存在kafka本地，當然了這裏的本地是指磁盤不是內存。。。
8）消費者註冊：每個消費者服務器啟動時，都會到Zookeeper的指定節點下創建壹個屬於自己的消費者節點，例如/consumers/[group_id]/ids/[consumer_id]，完成節點創建後，消費者就會將自己訂閱的Topic信息寫入該臨時節點。 對 消費者分組 中的 消費者 的變化註冊監聽 。每個 消費者 都需要關註所屬 消費者分組 中其他消費者服務器的變化情況，即對/consumers/[group_id]/ids節點註冊子節點變化的Watcher監聽，壹旦發現消費者新增或減少，就觸發消費者的負載均衡。 對Broker服務器變化註冊監聽 。消費者需要對/broker/ids/[0-N]中的節點進行監聽，如果發現Broker服務器列表發生變化，那麽就根據具體情況來決定是否需要進行消費者負載均衡。 進行消費者負載均衡 。為了讓同壹個Topic下不同分區的消息盡量均衡地被多個 消費者 消費而進行 消費者 與 消息 分區分配的過程，通常，對於壹個消費者分組，如果組內的消費者服務器發生變更或Broker服務器發生變更，會發出消費者負載均衡。