前言
前段時間寫了三個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
民那晚安。祝身體健康，百毒不侵。
