更新時間:2023-10-18 來源:黑馬程序員 瀏覽量:
Kafka消費(fèi)者消費(fèi)數(shù)據(jù)的速度是非??斓?,但如果由于處理Kafka消息時,由于有一些外部IO、或者是產(chǎn)生網(wǎng)絡(luò)擁堵,就會造成Kafka中的數(shù)據(jù)積壓(或稱為數(shù)據(jù)堆積)。如果數(shù)據(jù)一直積壓,會導(dǎo)致數(shù)據(jù)出來的實(shí)時性受到較大影響。
按照以下步驟查看分區(qū)消費(fèi)數(shù)據(jù)的積壓情況。
當(dāng)Kafka出現(xiàn)數(shù)據(jù)積壓問題時,首先要找到數(shù)據(jù)積壓的原因。以下是在企業(yè)中出現(xiàn)數(shù)據(jù)積壓的幾個類場景。
某日運(yùn)維人員找到開發(fā)人員,說某個topic的一個分區(qū)發(fā)生數(shù)據(jù)積壓,這個topic非常重要,而且開始有用戶投訴。運(yùn)維非常緊張,趕緊重啟了這臺機(jī)器。重啟之后,還是無濟(jì)于事。
消費(fèi)這個topic的代碼比較簡單,主要就是消費(fèi)topic數(shù)據(jù),然后進(jìn)行判斷在進(jìn)行數(shù)據(jù)庫操作。運(yùn)維通過kafka-eagle找到積壓的topic,發(fā)現(xiàn)該topic的某個分區(qū)積壓了幾十萬條的消息。
最后,通過查看日志發(fā)現(xiàn),由于數(shù)據(jù)寫入到MySQL中報錯,導(dǎo)致消費(fèi)分區(qū)的offset一自沒有提交,所以數(shù)據(jù)積壓嚴(yán)重。
基于Kafka開發(fā)的系統(tǒng)平穩(wěn)運(yùn)行了兩個月,突然某天發(fā)現(xiàn)某個topic中的消息出現(xiàn)數(shù)據(jù)積壓,大概有幾萬條消息沒有被消費(fèi)。
通過查看應(yīng)用程序日志發(fā)現(xiàn),有大量的消費(fèi)超時失敗。后查明原因,因為當(dāng)天網(wǎng)絡(luò)抖動,通過查看Kafka的消費(fèi)者超時配置為50ms,隨后,將消費(fèi)的時間修改為500ms后問題解決。