Kafka 消費者組 Rebalance 詳細過程

這是我參與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 後可以正常消費資料的狀態。

他們的關係如下圖：

Rebalance 的過程

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

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

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

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

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

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

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