Rebalance情境

• 現在我們已經知道，當某些情況發生變化時，Kafka會自動重新分配 Partition的Consumer，這個過程被稱為 Rebalance。本文以我們的Line Bot專案為例，以一個簡單的情境，說明當Consumer Instance變動時，Rebalance的運作過程。

• 假設情境如下:

• 1.訊息的傳送及接收

  • 如先前的文章所述，當使用者輸入訊息後，AWS Lambda扮演Producer的角色，將訊息傳送至Kafka Topic，這些訊息會由我們的 Consumer(也就是 Bot Server)來消費。

• 2.訊息與Topic分類

  • 在此專案中，使用者的訊息分為兩種：飲食紀錄和訓練紀錄，分別存放在不同的 Topic：
    飲食紀錄: 關於每日三餐吃的食物內容, topic 為 diet
訓練記錄: 關於重量訓練的動作和組次數紀錄, topic 為 training
  • 假設這兩個Topic各有兩個Partition

• 3.Consumer

  • 假設我們只有一個Consumer Group，訂閱了這兩個Topic。

初始狀態：單一Consumer instance

• 由於作者經費有限，我們只有一個Consumer Instance能用。
• 由於只有一個Bot Server，Kafka將所有的Partition都分配給這個Consumer instance。
  

加入新的Consumer Instance

• 現在專案突然大受好評，我們有了抖內拿來增加效能，加入了3個新的Consumer Instance。
• 此時Kafka會觸發Rebalance，把原本分派給Consumer 0的Partition重新分配給其他的Instance。
• 當Consumer Instance數量夠多時，Kafka會盡可能地讓每個Partition剛好被分配給一個Consumer Instance，如下:
  

移除Consumer Instance

• 假設其中一台Instance: Consumer 3壞了，為了維持系統穩定，我們要先把它移除。
• 此時Kafka再次觸發Rebalance，把Consumer 3負責的Partition改分配給其他Instance，例如將 training的Partition 1 分配給 Consumer 2。
  
• 因為現在Consumer Instance的數量小於Partition的數量，所以Consumer 2要負責消費兩個Partition。這個Partition中，Event的處理效能會比4個Instane時稍微差一點。
• 但由於先前提到的Commit Offset機制，Consumer 2會知道Consumer 3下線前的進度，而得以順從正確的Offset位置接手。

加入多餘的Consumer Instance

• 現在機器都開好了，但作者不小心手滑，開了兩台Consumer Instance，此時Consumer數量大於 Partition數量，會造成閒置，也就是有一台Bot Server是永遠不會去消費訊息的。因為每個Partition只能被指派給一個Consumer instance消費。
  

結論

以上用我們專案可能遇到的情境，希望能幫助讀者對Partition分配的機制更清楚。
Rebalance確保每個Partition的資料都能被有效消費，並且當Consumer數量與Partition數量不同時，也能自動調整Consumer的工作負載。

在接下來的文章中，也會以我們專案的需要為出發點，介紹Kafka在部署時會需要的設定。