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

創(chuàng)新互聯(lián)從2013年成立，先為四川等服務(wù)建站，四川等地企業(yè)，進(jìn)行企業(yè)商務(wù)咨詢服務(wù)。為四川企業(yè)網(wǎng)站制作PC+手機(jī)+微官網(wǎng)三網(wǎng)同步一站式服務(wù)解決您的所有建站問題。

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

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

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

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

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

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

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

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

reblance generation

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

reblance協(xié)議

Kafka會(huì)使用以下4組請求來完成reblance。

• JoinGroup：consumer請求入組

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

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

• LeaveGroup：consumer主動(dòng)請求coordinator自己將要離組

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

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

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

reblance流程

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

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

reblance主要分為兩步進(jìn)行：

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

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

看完上述內(nèi)容，你們對如何分析Kafka中的reblance有進(jìn)一步的了解嗎？如果還想了解更多知識或者相關(guān)內(nèi)容，請關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道，感謝大家的支持。