如何分析Kafka中的reblance

今天就跟大家聊聊有關如何分析Kafka中的reblance，可能很多人都不太了解，為了讓大家更加了解，小編給大家總結了以下內容，希望大家根據(jù)這篇文章可以有所收獲。

Kafka常見的消費模式會以組進行組織，通常Kafa會將Topic的分區(qū)均勻的分配給同一個組下的不同實例，通常的策略有以下三種：

• Range：將單個Topic的所有分區(qū)按照順序排列，然后把這些分區(qū)劃分成固定大小的分區(qū)段并分配給每個consumer，默認策略

• Round：將訂閱所有的Topic分區(qū)輪詢分配給每個conumser

• Sticky：規(guī)避數(shù)據(jù)傾斜，最大限度保證兩次reblance間維持之前的分配方案

目前觸發(fā)reblance主要有以下幾種情況：

• 組成員發(fā)生變更：新consumer加入離開組、consumer意外崩潰

• 組訂閱的Topic數(shù)發(fā)生變化：比如基于正則表達式的訂閱，當匹配正則表達式的新Topic被創(chuàng)建時

• 組訂閱的Topic的分區(qū)數(shù)目發(fā)生變更時

reblance generation

consumer group可以執(zhí)行多次reblance，為了保護consumer group特別是防止無效的offset提交，reblance generation通常用來標識某次reblance，每經歷一次reblance該值都會加1，默認值是從0開始。假如一個genertion值為1的consumer發(fā)生了延遲提交，但是reblance已經產生了新的group成員并且generation值已經變?yōu)榱?，那么該conumse的提交將會被拒絕(ILLEGAL_EXCEPTION)。

reblance協(xié)議

Kafka會使用以下4組請求來完成reblance。

• JoinGroup：consumer請求入組

• SyncGroup：group leader把分配方案同步更新到組內所有成員中

• HeartBeat：consumer定期向coordinator匯報心跳表明自己依然存活

• LeaveGroup：consumer主動請求coordinator自己將要離組

除了上面4組請求外，還有一個特殊的請求：

• DescribeGroup：查看組的所有信息，包括成員信息、協(xié)議信息、分配方案以及訂閱信息等。該請求不參與reblance，主要是管理員使用。

reblance過程中，coordinator需要接收來自consumer的JoinGroup和SyncGroup請求。當reblance成功以后，consumer定期向coordinator發(fā)送HeartBeat請求，consumer同時也會根據(jù)HeartBeat響應中是否包含REBLANCEINPROCESS來判斷當前group是否開啟了新一輪reblance。當consumer主動離組時，需要向coordinator發(fā)送LeaveGroup請求。

reblance流程

consumer reblance之前需要首先選定coordinator所在的broker(并且建立Socket連接)，算法：

• Math.abs(groupId.hashCode)%offsets.topic.num.partitions。

reblance主要分為兩步進行：

1. 加入組：組內的所有consumer向coordinator發(fā)送JoinGroup請求，當收集好所有的JoinGroup請求后，coorinator需要從中選一個group leader，并把所有成員信息以及他們的訂閱信息發(fā)送給leader。

2. 同步更新分配方案：group leader負責分配消費方案，具體策略有文章開頭的三種。分配完成后，leader會將分配方案封裝進SyncGroup請求然后發(fā)送給coordinator。在這一步中所有的consumer都會發(fā)送SyncGroup請求，只不過只有l(wèi)eader中包含了分配方案。coordinator收到請求后，將每個consumer的消費信息進行抽取然后作為SyncGroup的響應發(fā)送給對應的consumer。

看完上述內容，你們對如何分析Kafka中的reblance有進一步的了解嗎？如果還想了解更多知識或者相關內容，請關注億速云行業(yè)資訊頻道，感謝大家的支持。