Kafka 消費者組 Rebalance 詳細過程

語言: CN / TW / HK

這是我參與11月更文挑戰的第22天,活動詳情檢視:2021最後一次更文挑戰

相關:Kafka 中的消費者組Kafka 之如何避免 Rebalance

Rebalance 的觸發

之前的文章介紹了 Rebalance 觸發的三大類情況,即主題發生變化、主題分割槽發生變化、消費者組成員發生變化。其中,實際生產中消費者組成員變化導致的 Rebalance 是最常見的,消費者組成員的依次啟動也屬於這種情況。

本文主要討論消費者組成員發生變化時,Rebalance 的詳細過程。

協調者

在 Rebalance 的過程,不僅需要消費者組內成員的相互協調,還需要一個叫做「協調者」的角色參與。

協調者,也叫做 Coordinator,它是一個專門為消費者群提供服務的角色,主要負責 Rebalance 的執行、位移管理、組成員管理等。

協調者存在於 Broker 中,每個消費者例項都有其對應的協調者,消費者例項在啟動、提交位移等操作時,其實都是在向它對應的協調者所在的 Broker 傳送請求。

消費者例項如果找到自己的協調者對應的 Broker 呢?前面我們說過,消費者例項的位移資訊儲存在 Kafka 內部建立的位移主題中,先找到當前消費者組的資料儲存在位移主題的那個分割槽中,該分割槽的 Leader Replica 副本所在的 Broker 就是對應的協調者所在的 Broker。

消費者組的幾種狀態

瞭解了協調者這個角色,接下來介紹,協調者在管理消費者組成員的時候,會對消費者組標定狀態。在協調者的視角,消費者組一共有 5 種狀態:

  • Empty:表示組內沒有任何成員,但可能存在已經提交的位移資料,而且這些資料還沒有過期。
  • Dead:表示組內沒有任何成員,而且元資訊已經被移除。
  • PreparingRebalance:表示準備開始 Rebalance,所有消費成員都需要重新向協調者請求加入消費者組。
  • CompletingRebalance:表示所有的成員已經重新加入消費者組,正在等待分配方案。
  • Stable:表示穩定狀態,也就是完成 Rebalance 後可以正常消費資料的狀態。

他們的關係如下圖:

流程圖.jpg

Rebalance 的過程

當消費者組處於 Stable 狀態時,消費者例項會定期向協調者傳送心跳通知,起作用就是告訴協調者例項在正常執行,當有新成員計入、成員主動離開、成員失聯被動離開的場景下,協調者會通過響應心跳請求的方式,告訴所有例項,要進行 Rebalance 了。

我們分別梳理一下協調者發起新一輪 Rebalance 前,這三種情況的流程。

  • 第一種,當有新的例項加入的時候,新加入的例項會向協調者傳送 JoinGroup 請求,協調者收到後,會向所有例項響應新一輪 Rebalance 開始的資訊。
  • 第二種,當有成員主動離開消費者組,離組的成語啊你會向協調者傳送 LeaveGroup 的請求,協調者收到後,會向所有例項響應新一輪 Rebalance 開始的資訊。
  • 第三種,協調者沒有在規定時間內接收到某個成員的心跳通知,那麼這個成員會被踢出消費者組,測試,協調者會向所有例項響應新一輪 Rebalance 開始的資訊。

以上所說的開始新一輪 Rebalance 的資訊,其實就是在心跳請求的響應中,告訴成員:Rebalance 要開始了,請重新申請加入消費者組。成員收到後,會重新發送 JoinGroup 請求。

當協調者收到所有成員的 JoinGroup 請求後,會在所有成員中選定一個 Leader,通常是第一個發起 JoinGroup 請求的成員。協調者會把所有成員及其訂閱的主題,發給這個 Leader,由它來為每一個成員分配消費的主題分割槽。

在此過程中,組內的成員會向協調者傳送 SyncGroup 請求,等待接收 Leader 分配好的方案。當所有的成員都接收到新的分配方案後,Rebalance 就完成了。

還有一個需要了解的地方是,當 Rebalance 開啟的時候,協調者會給成員一定的時間,來提交自己當前的位移資訊,然後在開始 JoinGroup 和 SyncGroup 請求。