Kafka

文章地址

下面這篇文章很棒：文章地址

該連結主要內容：

Kafka叢集中的其中一個Broker會被選舉為Controller

一個topic可具有多個partition，但Partition一定屬於一個topic。

• 消費時，每個消費執行緒最多隻能使用一個partition。
• 一個topic中partition的數量，就是每個user group中消費該topic的最大並行度數量。（Partition則是Consumer消費的基本單元，即topic1有幾個partition，那麼最多就可以有多少個consumer同時在一個User Group裡消費這個topic）

為了便於實現MQ中的多播，重複消費等引入的概念。如果ConsumerA以及ConsumerB同在一個UserGroup，那麼ConsumerA消費的資料ConsumerB就無法消費了。即：所有usergroup中的consumer使用一套offset。

User1，User2同屬一個userGroup時，即表示二者共用一套Offset。因每個partition 的offset只能由一個執行緒維護，因此註定了每個UserGroup裡只能有一個消費執行緒對一個partition進行消費。

Offset專指Partition以及User Group而言，記錄某個user group在某個partiton中當前已經消費到達的位置。

kafkaServer（broker）不直接負責每個consumer的當前消費到了哪裡，所以需要client端和zk聯合維護每個partition讀到了哪裡，即Offset。

大部分訊息都會被順序讀取，當然也會存在少量的隨機讀取訊息（比如處理的時候這條訊息處理失敗，需要重新處理）。所以索引在這裡的意義僅為簡單支援少量隨機查詢。所以在索引的實現上，基本上就是為了支援針對某個Offset進行二分查詢而存在的索引。

Kafka自己的In-Sync Replicas（ISR）機制

“以一段時間而非以一個訊息為基本單位，進行可靠性保障”這是ISR機制最核心的思想

controller在啟動時會註冊zk監聽器來監聽zookeeper中的/brokers/ids節點下子節點的變化，即叢集所有broker列表，而每臺broker在啟動時會向zk的/brokers/ids下寫入一個名為broker.id的臨時節點，當該broker掛掉或與zk斷開連線時，此臨時節點會被移除（這是zk提供的功能），之後controller端的監聽器就會自動感知到這個變化並將BrokerChange事件寫入到controller上的請求阻塞佇列中。

一旦controller端從阻塞佇列中獲取到該事件，它會開啟BrokerChange事件的處理邏輯，具體包含：

1. 獲取當前存活的所有broker列表

2. 根據之前快取的broker列表計算出當前“已掛掉”的broker列表

3. 更新controller端快取

4. 對於當前所有存活的broker，更新元資料資訊並且啟動新broker上的分割槽和副本

5. 對於“掛掉”的那些broker，處理這些broker上的分割槽副本（標記為offline以及執行offline邏輯並更新元資料等）

至於zk為什麼會知道是否失連，zk -> kafka 搭建服務的時候，你自己設定的心跳時間，如果超過心跳時間沒有連線到就會斷開連線。