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 請求。