談?wù)凨afka Consumer Group的Coordinator與Rebalance機(jī)制

前言

前段時間寫了三個Spark Streaming程序,負(fù)責(zé)從Kafka訂閱群和用戶消息,并做輿情監(jiān)控必須的ETL工作。它們消費(fèi)的Topic各自不同,但是分配的group.id都相同。運(yùn)行一段時間之后,發(fā)現(xiàn)偶爾拋出如下所示的異常。

ERROR [org.apache.spark.streaming.scheduler.JobScheduler] - Error generating jobs for time 1579570560000 ms
java.lang.IllegalStateException: No current assignment for partition my_dummy_topic-11
    at org.apache.kafka.clients.consumer.internals.SubscriptionState.assignedState(SubscriptionState.java:251)
    at org.apache.kafka.clients.consumer.internals.SubscriptionState.needOffsetReset(SubscriptionState.java:315)
    at org.apache.kafka.clients.consumer.KafkaConsumer.seekToEnd(KafkaConsumer.java:1170)
    at org.apache.spark.streaming.kafka010.DirectKafkaInputDStream.latestOffsets(DirectKafkaInputDStream.scala:192)
    at org.apache.spark.streaming.kafka010.DirectKafkaInputDStream.compute(DirectKafkaInputDStream.scala:209)
......

經(jīng)過Google確定是由于我們使用的Spark Streaming 2.3版本無法處理Kafka Consumer Rebalance而引起的,見SPARK-22968及其對應(yīng)的PR。我們通過進(jìn)一步查看日志,確實(shí)發(fā)生了Rebalance。

那么本文就來說說Rebalance機(jī)制,先從執(zhí)行Rebalance的主體——Consumer Group談起。

Consumer Group

為了使得Consumer易于組織、可擴(kuò)展以及更好地容錯,Kafka將一個或多個Consumer組織為Consumer Group,即消費(fèi)者組。Consumer Group的唯一標(biāo)識就是group.id。Group內(nèi)的所有Consumer共同消費(fèi)已訂閱的各個Topic的所有Partition,并且保證每個Partition只分配給該Group內(nèi)的唯一一個Consumer。對Consumer Group的管理就是實(shí)現(xiàn)以下三個職責(zé):

  • 分配并維護(hù)Consumer與Partition的消費(fèi)對應(yīng)關(guān)系,即"who owns what"。(重新)分配消費(fèi)對應(yīng)關(guān)系的過程就叫Rebalance
  • 記錄并提交Consumer消費(fèi)Partition的消費(fèi)位點(diǎn)(Offset值),即"consumed up to where";
  • 維護(hù)Consumer Group的配置信息與Consumer元數(shù)據(jù)。

下面簡單介紹Consumer Group的管理。

Group Coordinator

在0.9版本之前,Kafka強(qiáng)依賴于ZooKeeper實(shí)現(xiàn)Consumer Group的管理:

  • Group內(nèi)每個Consumer通過在ZK內(nèi)搶注節(jié)點(diǎn)來決定消費(fèi)哪些Partition,并注冊對Group和Broker相關(guān)節(jié)點(diǎn)的監(jiān)聽,以獲知消費(fèi)環(huán)境的變化(其他Consumer掉線、Broker宕機(jī)等),進(jìn)而觸發(fā)Rebalance;
  • Offset值也維護(hù)在ZK中,老生常談了。

這種方式除了過于依賴ZK,導(dǎo)致ZK壓力偏大之外,還有兩個分布式系統(tǒng)中常見且嚴(yán)重的問題:

  • 羊群效應(yīng)(herd effect)——一個被監(jiān)聽的ZK節(jié)點(diǎn)發(fā)生變化,導(dǎo)致大量的通知發(fā)送給所有監(jiān)聽者(即Consumer);
  • 腦裂(split brain)——ZK只保證最終一致性,不同的Consumer在同一時刻可能看到不同的Group和Broker狀態(tài),造成Rebalance混亂。

所以從0.9版本開始,Kafka重新設(shè)計(jì)了名為Group Coordinator的“協(xié)調(diào)者”服務(wù)負(fù)責(zé)實(shí)現(xiàn)上述職責(zé),將這部分工作從ZK剝離開來。每個Broker在啟動時,都會順帶啟動一個Group Coordinator實(shí)例。每個Consumer Group在初始化時,都會分配給一個Group Coordinator實(shí)例來管理消費(fèi)關(guān)系和Offset,如下簡圖所示。

https://img.hchstudio.cn/The%20Silver%20Bullet%20for%20Endless%20Rebalancing.pdf

Group Coordinator提交Offset時也不再是向ZK寫,而是寫入那個廣為人知的特殊Topic——__consumer_offsets里。key是group-topic-partition格式的,value為Offset值。

那么該如何確定一個Consumer Group被分配給哪個Group Coordinator呢?Kafka根據(jù)groupId.hashCode() % offsets.topic.num.partitions取絕對值來得出該Group的Offset信息寫入__consumer_offsets的分區(qū)號,并將Group分配給該分區(qū)Leader所在的Broker上的那個Group Coordinator。

上面粗略講了Group Coordinator和它的第二個職責(zé)的實(shí)現(xiàn)方式,接下來仔細(xì)分析第一個職責(zé),就是Rebalance的機(jī)制。

Rebalance觸發(fā)條件與協(xié)議

我們已經(jīng)知道,Rebalance就是一個Consumer Group內(nèi)的所有Consumer分配消費(fèi)各已訂閱的Topic的各Partition的過程。Partition的分配有內(nèi)置的三種算法實(shí)現(xiàn)(range、round-robin、sticky),用戶也可以自定義分配規(guī)則,這個與本文關(guān)系不太大,就不再展開說。

那么有哪些條件會觸發(fā)Rebalance呢?列舉如下:

  • Group發(fā)生變更,即新的Consumer加入,或原有的Consumer離開。Consumer離開可以是主動的(退出),也可以是被動的(崩潰);
  • Partition發(fā)生變更,包含訂閱的Topic被創(chuàng)建或刪除,以及現(xiàn)有訂閱Topic新增Partition等。

本文只考慮Group發(fā)生變更的情況。Kafka定義了一個簡單的協(xié)議來處理這種情況下的Rebalance過程,包含以下4對請求/響應(yīng):

  • heartbeat:Group中的Consumer周期性地給Coordinator發(fā)送該心跳信號,表示自己存活;
  • join-group:Consumer請求加入Group的信號;
  • leave-group:Consumer主動退出Group的信號;
  • sync-group:Coordinator將已生成的Consumer-Partition消費(fèi)對應(yīng)關(guān)系分發(fā)給Consumer的信號。

下面三張圖示出心跳超時(被動退出)、主動退出和加入Group的情況。

心跳超時——注意heartbeat.interval.ms與session.timeout.ms兩個參數(shù)的作用
主動退出Group
加入Group

圖中的紅色嘆號表示Coordinator感知到了變化,并觸發(fā)Rebalance過程。

Rebalance過程

整個Rebalance分為兩個大步驟:JOIN和SYNC。

JOIN

正如其名,在這一步中,所有Consumer都會向Coordinator發(fā)送join-group,請求重新加入Group(那些原本已經(jīng)在Group內(nèi)的也不例外),同時放棄掉已分配給自己的Partition。以有新的Consumer主動加入Group(即上一節(jié)中的第三種情況)為例,圖示如下。

圖中的sync. barrier線就是表示JOIN步驟與SYNC步驟之間的分界,即從發(fā)起Rebalance開始到接受最后一個join-group之間的超時。需要特別注意的是,Broker端和Consumer端判定這個階段超時的標(biāo)準(zhǔn)是不同的,Broker端使用rebalance.timeout.ms,而Consumer端使用max.poll.interval.ms。所以當(dāng)遇到不明原因的長時間Rebalance時,應(yīng)考慮max.poll.interval.ms的設(shè)定。

SYNC

這一步需要做的事情是:

  • Coordinator在所有Consumer里選擇一個擔(dān)任Leader,并由Leader調(diào)用Partition分配規(guī)則來確定消費(fèi)對應(yīng)關(guān)系。
  • 各個Consumer發(fā)送sync-group請求。Leader發(fā)送的請求里包含有已經(jīng)確定的消費(fèi)分配信息,其他Consumer的請求為空。
  • Coordinator將消費(fèi)分配信息原樣封裝在sync-group響應(yīng)中,并投遞給各個Consumer,最終使Group內(nèi)所有成員都獲知自己該消費(fèi)的Partition。

圖示如下,其中C1被選為Leader。SYNC步驟結(jié)束后,原有的1~6六個分區(qū)被分配給了C1~C3三個Consumer。Rebalance就完成了。

Rebalance的改進(jìn)方案

上述Rebalance機(jī)制沿用了很長時間,但是它同樣存在問題:

  • stop-the-world問題——需要收回(revoke)所有Partition再重新分配(reassign),在此時間內(nèi),所有Consumer都無法進(jìn)行消費(fèi)。如果Rebalance時間長,會造成lag。
  • back-and-forth問題——如果多次觸發(fā)Rebalance,很有可能造成一個Consumer消費(fèi)的Partition被分配給其他Consumer,然后又分配回來,做了無用功。

為了解決該問題,在2.4版本特別提出了Incremental(增量)Rebalance。顧名思義,就是Rebalance時不再讓所有Consumer都放棄掉所有已分配的Partition,而是每次先記錄,并轉(zhuǎn)化成多次少量的Rebalance過程,且Consumer在此期間不會STW。簡圖如下所示。

關(guān)于該方案的細(xì)節(jié),請參考KIP-429

The End

民那晚安。祝身體健康,百毒不侵。

?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
平臺聲明:文章內(nèi)容(如有圖片或視頻亦包括在內(nèi))由作者上傳并發(fā)布,文章內(nèi)容僅代表作者本人觀點(diǎn),簡書系信息發(fā)布平臺,僅提供信息存儲服務(wù)。
  • 序言:七十年代末,一起剝皮案震驚了整個濱河市,隨后出現(xiàn)的幾起案子,更是在濱河造成了極大的恐慌,老刑警劉巖,帶你破解...
    沈念sama閱讀 230,825評論 6 546
  • 序言:濱河連續(xù)發(fā)生了三起死亡事件,死亡現(xiàn)場離奇詭異,居然都是意外死亡,警方通過查閱死者的電腦和手機(jī),發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 99,814評論 3 429
  • 文/潘曉璐 我一進(jìn)店門,熙熙樓的掌柜王于貴愁眉苦臉地迎上來,“玉大人,你說我怎么就攤上這事。” “怎么了?”我有些...
    開封第一講書人閱讀 178,980評論 0 384
  • 文/不壞的土叔 我叫張陵,是天一觀的道長。 經(jīng)常有香客問我,道長,這世上最難降的妖魔是什么? 我笑而不...
    開封第一講書人閱讀 64,064評論 1 319
  • 正文 為了忘掉前任,我火速辦了婚禮,結(jié)果婚禮上,老公的妹妹穿的比我還像新娘。我一直安慰自己,他們只是感情好,可當(dāng)我...
    茶點(diǎn)故事閱讀 72,779評論 6 414
  • 文/花漫 我一把揭開白布。 她就那樣靜靜地躺著,像睡著了一般。 火紅的嫁衣襯著肌膚如雪。 梳的紋絲不亂的頭發(fā)上,一...
    開封第一講書人閱讀 56,109評論 1 330
  • 那天,我揣著相機(jī)與錄音,去河邊找鬼。 笑死,一個胖子當(dāng)著我的面吹牛,可吹牛的內(nèi)容都是我干的。 我是一名探鬼主播,決...
    沈念sama閱讀 44,099評論 3 450
  • 文/蒼蘭香墨 我猛地睜開眼,長吁一口氣:“原來是場噩夢啊……” “哼!你這毒婦竟也來了?” 一聲冷哼從身側(cè)響起,我...
    開封第一講書人閱讀 43,287評論 0 291
  • 序言:老撾萬榮一對情侶失蹤,失蹤者是張志新(化名)和其女友劉穎,沒想到半個月后,有當(dāng)?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體,經(jīng)...
    沈念sama閱讀 49,799評論 1 338
  • 正文 獨(dú)居荒郊野嶺守林人離奇死亡,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內(nèi)容為張勛視角 年9月15日...
    茶點(diǎn)故事閱讀 41,515評論 3 361
  • 正文 我和宋清朗相戀三年,在試婚紗的時候發(fā)現(xiàn)自己被綠了。 大學(xué)時的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片。...
    茶點(diǎn)故事閱讀 43,750評論 1 375
  • 序言:一個原本活蹦亂跳的男人離奇死亡,死狀恐怖,靈堂內(nèi)的尸體忽然破棺而出,到底是詐尸還是另有隱情,我是刑警寧澤,帶...
    沈念sama閱讀 39,221評論 5 365
  • 正文 年R本政府宣布,位于F島的核電站,受9級特大地震影響,放射性物質(zhì)發(fā)生泄漏。R本人自食惡果不足惜,卻給世界環(huán)境...
    茶點(diǎn)故事閱讀 44,933評論 3 351
  • 文/蒙蒙 一、第九天 我趴在偏房一處隱蔽的房頂上張望。 院中可真熱鬧,春花似錦、人聲如沸。這莊子的主人今日做“春日...
    開封第一講書人閱讀 35,327評論 0 28
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽。三九已至,卻和暖如春,著一層夾襖步出監(jiān)牢的瞬間,已是汗流浹背。 一陣腳步聲響...
    開封第一講書人閱讀 36,667評論 1 296
  • 我被黑心中介騙來泰國打工, 沒想到剛下飛機(jī)就差點(diǎn)兒被人妖公主榨干…… 1. 我叫王不留,地道東北人。 一個月前我還...
    沈念sama閱讀 52,492評論 3 400
  • 正文 我出身青樓,卻偏偏與公主長得像,于是被迫代替她去往敵國和親。 傳聞我的和親對象是個殘疾皇子,可洞房花燭夜當(dāng)晚...
    茶點(diǎn)故事閱讀 48,703評論 2 380

推薦閱讀更多精彩內(nèi)容