背景：

工作往往是千篇一律，真正能學(xué)到點(diǎn)知識(shí)都是在上線后。使用Skywalking+Kafka+ES進(jìn)行應(yīng)用監(jiān)控。

現(xiàn)象：

公司使用Skywalking在開發(fā)測試環(huán)境中Kafka順利消費(fèi)數(shù)據(jù)，到了UAT環(huán)境一開始還正常，后面接入了更多的應(yīng)用后出現(xiàn)了問題：OAP服務(wù)正常但是ES里不再有數(shù)據(jù)。

排查：

通過查看消費(fèi)者消費(fèi)Kafka數(shù)據(jù)的情況可以看到，數(shù)據(jù)出現(xiàn)了積壓。

?由于沒有設(shè)置消費(fèi)者的參數(shù)，所以使用的是默認(rèn)值max.poll.interval.ms是5分鐘、?max.poll.records是500

?目前積壓數(shù)據(jù)遠(yuǎn)大于一次拉取消費(fèi)的500，所以判斷是因?yàn)橄M(fèi)者無法在等待時(shí)間內(nèi)消費(fèi)完數(shù)據(jù)，?Consumer ?Group Coordination消費(fèi)組判定當(dāng)前消費(fèi)者不在消費(fèi)組內(nèi)，所以查詢消費(fèi)者狀態(tài)會(huì)出現(xiàn)消費(fèi)者組不存在消費(fèi)成員（如圖符合判斷）

?目前解決方法：

max.poll.records改小或者?request.timeout.ms改大或者?request.timeout.ms改大，因?yàn)槟壳皵?shù)據(jù)不穩(wěn)定后續(xù)也只能通過數(shù)據(jù)量進(jìn)行修改參數(shù)調(diào)優(yōu)。重新開始消費(fèi)，待后續(xù)觀察。

結(jié)論：

由于數(shù)據(jù)量變大，消費(fèi)者長時(shí)間不再請求數(shù)據(jù)，未向Group Coordinator發(fā)送心跳請求，所以kafka認(rèn)為消費(fèi)者已從消費(fèi)組下線。所以不再進(jìn)行消費(fèi)。

學(xué)習(xí)：

之前知識(shí)淺淺了解了Rebalance，但沒碰到過。所以借此好好學(xué)習(xí)一下。

一、什么是Rebalance

• Rebalance本質(zhì)上是一種協(xié)議, 規(guī)定了一個(gè)Consumer Group下的所有consumer如何達(dá)成一致,來分配訂閱Topic的每個(gè)分區(qū)。

• Rebalance發(fā)生時(shí), 所有的Consumer Group都停止工作, 直到Rebalance 成。

二、觸發(fā)條件

① 組成員個(gè)數(shù)發(fā)生變化

• 新的消費(fèi)者加入到消費(fèi)組

• 消費(fèi)者主動(dòng)退出消費(fèi)組

• 消費(fèi)者被動(dòng)下線。比如消費(fèi)者長時(shí)間的GC, 網(wǎng)絡(luò)延遲導(dǎo)致消費(fèi)者長時(shí)間未向Group Coordinator發(fā)送心跳請求, 均會(huì)認(rèn)為該消費(fèi)者已經(jīng)下線并踢出（本次問題出現(xiàn)的原因）

② 訂閱的Topic的Consumer Group個(gè)數(shù)發(fā)生變化

③ Topic 的分區(qū)數(shù)發(fā)生變化

三、Rebalance的弊端

1. rebalance的時(shí)候消費(fèi)組內(nèi)的所有消費(fèi)者都不能處理消息
2. 消費(fèi)組內(nèi)的消費(fèi)者越多rebalance時(shí)間越長

3. Rebalance 效率不高。當(dāng)前 Kafka 的設(shè)計(jì)機(jī)制決定了每次 Rebalance 時(shí)，Consumer Group 下的所有成員都要參與進(jìn)來，而且通常不會(huì)考慮局部性原理，但局部性原理對提升系統(tǒng)性能是特別重要的。

四、如何避免Rebalance

從觸發(fā)條件可以看到，① 、?② 、③基本都是可以認(rèn)為盡量避免也就是提前根據(jù)數(shù)據(jù)量規(guī)劃好消費(fèi)者數(shù)量，主要是① 中的第三個(gè)，需要靠kafka的參數(shù)去調(diào)整

#?心跳相關(guān)
session.timeout.ms?=?6s
heartbeat.interval.ms?=?2s
#?消費(fèi)數(shù)量(默認(rèn)500)
max.poll.records


#?消費(fèi)時(shí)間(默認(rèn)300000)
request.timeout.msmax.poll.interval.ms=300000

?

五、Rebalance過程

Coordinator服務(wù)

• Group Coordinator 是一個(gè)服務(wù), 每個(gè) Broker 在啟動(dòng)的時(shí)候都會(huì)啟動(dòng)一個(gè)該服務(wù) Group Coordinator 的作用是用來存儲(chǔ) Group 的相關(guān) Meta 信息, 并將對應(yīng) Partition 的 Offset 信息記錄到 Kafka 內(nèi)置 Topic(__consumer_offsets)中

• Kafka 在0.9之前是基于 Zookeeper 來存儲(chǔ)Partition的 offset 信息(consumers/{group}/offsets/{topic}/{partition}), 因?yàn)?Zookeeper 并不適用于頻繁的寫操作, 所以在0.9之后通過內(nèi)置 Topic 的方式來記錄對應(yīng) Partition 的 offset。

Rebalance過程分為兩步：Join Group和 Sync Group。

Join Group

① 概述

• Join Group 顧名思義就是加入組。

• 這一步中, 所有成員都向 Coordinator 發(fā)送 JoinGroup 請求, 請求加入消費(fèi)組。

• 一旦所有成員都發(fā)送了 JoinGroup 請求, Coordinator 會(huì)從中選擇一個(gè) Consumer 擔(dān)任 Leader 的角色, 并把組成員信息以及訂閱信息發(fā)給 Consumer Leader。

• 注意Consumer Leader 和 Coordinator不是一個(gè)概念。Consumer Leader負(fù)責(zé)消費(fèi)分配方案的制定。

② 流程圖

?Sync Group

① 概述

• Consumer Leader 開始分配消費(fèi)方案，即哪個(gè) Consumer 負(fù)責(zé)消費(fèi)哪些 Topic 的哪些 Partition。

• 一旦完成分配，Consumer Leader 會(huì)將這個(gè)方案封裝進(jìn)SyncGroup請求中發(fā)給 Coordinator。

• 非 Consumer Leader 也會(huì)發(fā) SyncGroup 請求, 只是內(nèi)容為空。

• Coordinator 接收到分配方案之后會(huì)把方案塞進(jìn)SyncGroup的Response中發(fā)給各個(gè)Consumer。

• 這樣組內(nèi)的所有成員就都知道自己應(yīng)該消費(fèi)哪些分區(qū)了。

② 流程圖

參考：Kafka學(xué)習(xí)筆記 NO.004 Kafka的Rebalance(重平衡) - 墨天輪文章來源地址http://www.zghlxwxcb.cn/news/detail-413284.html

到了這里，關(guān)于Kafka消費(fèi)者不消費(fèi)數(shù)據(jù)的文章就介紹完了。如果您還想了解更多內(nèi)容，請?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！