Kafka Consumer 的 Rebalance 機制-原文連結
Kafka Consumer 的 Rebalance 機制-原文連結
Kafka Consumer 的 Rebalance 機制-原文連結
上週參加了 Kafka Meetup 北京站的技術分享,本文簡單介紹下 Kafka Consumer 的 Rebalance 機制以及其新版本中的優化策略~
Kafka 之前版本的 Consumer Groups
Consumer Group
如上圖所示,Consumer
使用 Consumer Group
名稱標記自己,並且釋出到主題的每條記錄都會傳遞到每個訂閱消費者組中的一個 Consumer
例項。 Consumer
例項可以在單獨的程式中或在單獨的機器上。
如果所有 Consumer
例項都屬於同一個 Consumer Group
,那麼這些 Consumer
例項將平衡再負載的方式來消費 Kafka
。
如果所有 Consumer
例項具有不同的 Consumer Group
,則每條記錄將廣播到所有 Consumer
程式。
Group Coordinator
Group Coordinator
是一個服務,每個 Broker
在啟動的時候都會啟動一個該服務。Group Coordinator
的作用是用來儲存 Group
的相關 Meta
資訊,並將對應 Partition
的 Offset
資訊記錄到 Kafka
內建Topic(__consumer_offsets)
中。Kafka
在 0.9 之前是基於 Zookeeper
來儲存 Partition
的 Offset
資訊 (consumers/{group}/offsets/{topic}/{partition})
,因為 Zookeeper
並不適用於頻繁的寫操作,所以在 0.9 之後通過內建 Topic
的方式來記錄對應 Partition
的 Offset
。如下圖所示:
在 Kafka 0.8.2
之前是這樣的
之後是這樣的:
每個 Group
都會選擇一個 Coordinator
來完成自己組內各 Partition
的 Offset
資訊,選擇的規則如下:
- 計算
Group
對應在__consumer_offsets
上的Partition
- 根據對應的Partition尋找該Partition的leader所對應的Broker,該Broker上的Group Coordinator即就是該Group的Coordinator
Partition計算規則:
partition-Id(__consumer_offsets) = Math.abs(groupId.hashCode() % groupMetadataTopicPartitionCount)
複製程式碼
其中 groupMetadataTopicPartitionCount
對應 offsets.topic.num.partitions
引數值,預設值是 50 個分割槽
Consumer Rebalance Protocol
發生 rebalance 的時機
- 組成員個數發生變化。例如有新的
consumer
例項加入該消費組或者離開組。 - 訂閱的
Topic
個數發生變化。 - 訂閱
Topic
的分割槽數發生變化。
消費者程式掛掉的情況
session
過期heartbeat
過期
Rebalance
發生時,Group
下所有 Consumer
例項都會協調在一起共同參與,Kafka
能夠保證儘量達到最公平的分配。但是 Rebalance
過程對 Consumer Group
會造成比較嚴重的影響。在 Rebalance
的過程中 Consumer Group
下的所有消費者例項都會停止工作,等待 Rebalance
過程完成。
消費者的 Rebalance 協議
Rebalance 發生後的執行過程
1,有新的 Consumer
加入 Consumer Group
2,從 Consumer Group
選出 leader
3,leader
進行分割槽的分配
Issues
Known Issue #1: Stop-the-world Rebalance
如上圖所示:之前版本的Kafka
在發生 Rebalance
時候會釋放 Consumer Group
的所有資源,造成比較長的 Stop-the-world
Known Issue #2: Back-and-forth Rebalance
如上圖所示:在發生Rebalance
的時候發生的不必要的資源釋放與重新分配。
當前的 Rebalance 與 改進後的 ReBalance 對比
漸進式 Rebalance 協議
如上圖所示,新的漸進式 Rebalance 協議,在 Rebalance 的時候不需要當前所有的 Consumer 釋放所擁有的資源,而是當需要觸發 Rebalance 的時候對當前資源進行登記,然後進行漸進式的 Rebalance。 這樣做產生的優化效果- 相較之前進行了更多次數的 Rebalance,但是每次 Rebalance 對資源的消耗都是比較廉價的
- 發生遷移的分割槽相較之前更少了
- Consumer 在 Rebalance 期間可以繼續執行
參考文章
- Incremental Cooperative Rebalancing in Apache Kafka: Why Stop the World When You Can Change It?
- KIP-429: Kafka Consumer Incremental Rebalance Protocol
- Incremental Cooperative Rebalancing: Support and Policies