Kafka隨筆

 1.選舉Leader 

　　Leader 是 Partition 級別的，當一個 Broker 掛掉後，全部 Leader 在該 Broker 上的 Partition 都會被從新選舉，選出一個新 Leader。

　　Kafka 先使用 ZooKeeper 在 Broker 中選出一個 Controller，用於上述 Partition分配和 Leader 選舉。

　　Controller 會在 ZooKeeper 的 /brokers/ids 節點上註冊 Watch 監聽，一旦有 Broker 宕機，Controller就收到通知。 

　　Partition 分配： 

• 將全部 Broker（假設共 n 個 Broker）和待分配的 Partition 排序。
• 將第 i 個 Partition 分配到第（i mod n）個 Broker 上 （這個就是 Leader）。
• 將第 i 個 Partition 的第 j 個 Replica 分配到第（(i + j) mode n）個 Broker 上。

　　Leader 選舉：

　　　　Controller 從 ZooKeeper 的 /brokers / topics / [topic名稱] / partitions / [partition名稱] / state 中，讀取對應 Partition 的 ISR（in-sync replica 已同步的副本）列表，選一個出來作 Leader。 

　　　　ISR 列表中的機器是會變化的，根據配置 replica.lag.time.max.ms，多久沒同步，就會從 ISR 列表中去除。 

　　　　0.10版本以前，還有個參數是根據落後多少條消息就踢出 ISR，在 0.10 版本後就去掉了，由於這個值很難取，在高峯的時候很容易出現節點不斷的進出 ISR 列表的狀況。

　　　　選出 Leader 後，更新 ZooKeeper，而後Controller發送 LeaderAndISRRequest 給受影響的 Broker，通知全部相關Broker：新leader已產生。

　　　　選舉完成以後，全部對某個 Partition 的請求，實際操做的都是 Leader，而後其餘 Follower 再 Pull 消息同步。 

 

 

2.Partition的分發策略：

• Partition 在寫入的時候能夠指定須要寫入的 Partition，若是有指定，則寫入對應的 Partition。
• 若是沒有指定 Partition，可是設置了數據的 Key，則會根據 Key 的值 Hash 出一個 Partition。
• 若是既沒指定 Partition，又沒有設置 Key，則會輪詢 各個Partition。

 

3.Partition文件：

　　Partition 在操做系統中就是一個個的文件夾，每一個 Partition 的文件夾下面會有多組 Segment 文件。

　　每組 Segment 文件又包含 .index 文件、.log 文件、.timeindex 文件（早期版本中沒有）三個文件。

　　Log 文件就是實際存儲 Message 的地方，而 Index 和 Timeindex 文件爲索引文件，用於檢索消息。

　　文件的命名是以該 Segment 最小 Offset 來命名的，以下圖中間那個segment的命名是 368796.index， 存儲了Offset 爲 368796~1105813 的消息。

　　創建在 Offset 爲有序的基礎上，Kafka利用 Segment分段文件記錄+Segment文件內索引+有序Offset+稀疏索引+二分查找+順序查找等多種手段來高效的查找數據。

　　在0.10版本前，消費者將消費到的 Offset 維護在 Zookeeper 中，Consumer 每間隔一段時間上報一次，容易致使重複消費，且性能很差； 

　　0.10版本後，消費者消費到的 Offset 已經直接維護在 Kafka 集羣的 __consumer_offsets 這個Topic 中。