前言
前段時間寫了三個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,如下簡圖所示。
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的情況。
圖中的紅色嘆號表示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
民那晚安。祝身體健康,百毒不侵。