Kafka出現(xiàn)數(shù)據(jù)積壓?jiǎn)栴}怎樣解決？

Kafka消費(fèi)者消費(fèi)數(shù)據(jù)的速度是非?？斓模绻捎谔幚鞬afka消息時(shí)，由于有一些外部IO、或者是產(chǎn)生網(wǎng)絡(luò)擁堵，就會(huì)造成Kafka中的數(shù)據(jù)積壓(或稱為數(shù)據(jù)堆積)。如果數(shù)據(jù)一直積壓，會(huì)導(dǎo)致數(shù)據(jù)出來(lái)的實(shí)時(shí)性受到較大影響。

使用Kafka-Eagle查看數(shù)據(jù)積壓情況

按照以下步驟查看分區(qū)消費(fèi)數(shù)據(jù)的積壓情況。

解決數(shù)據(jù)積壓?jiǎn)栴}

當(dāng)Kafka出現(xiàn)數(shù)據(jù)積壓?jiǎn)栴}時(shí)，首先要找到數(shù)據(jù)積壓的原因。以下是在企業(yè)中出現(xiàn)數(shù)據(jù)積壓的幾個(gè)類場(chǎng)景。

1.數(shù)據(jù)寫入MySQL失敗

某日運(yùn)維人員找到開(kāi)發(fā)人員，說(shuō)某個(gè)topic的一個(gè)分區(qū)發(fā)生數(shù)據(jù)積壓，這個(gè)topic非常重要，而且開(kāi)始有用戶投訴。運(yùn)維非常緊張，趕緊重啟了這臺(tái)機(jī)器。重啟之后，還是無(wú)濟(jì)于事。

消費(fèi)這個(gè)topic的代碼比較簡(jiǎn)單，主要就是消費(fèi)topic數(shù)據(jù)，然后進(jìn)行判斷在進(jìn)行數(shù)據(jù)庫(kù)操作。運(yùn)維通過(guò)kafka-eagle找到積壓的topic，發(fā)現(xiàn)該topic的某個(gè)分區(qū)積壓了幾十萬(wàn)條的消息。

最后，通過(guò)查看日志發(fā)現(xiàn)，由于數(shù)據(jù)寫入到MySQL中報(bào)錯(cuò)，導(dǎo)致消費(fèi)分區(qū)的offset一自沒(méi)有提交，所以數(shù)據(jù)積壓嚴(yán)重。

2.因?yàn)榫W(wǎng)絡(luò)延遲消費(fèi)失敗

基于Kafka開(kāi)發(fā)的系統(tǒng)平穩(wěn)運(yùn)行了兩個(gè)月，突然某天發(fā)現(xiàn)某個(gè)topic中的消息出現(xiàn)數(shù)據(jù)積壓，大概有幾萬(wàn)條消息沒(méi)有被消費(fèi)。

通過(guò)查看應(yīng)用程序日志發(fā)現(xiàn)，有大量的消費(fèi)超時(shí)失敗。后查明原因，因?yàn)楫?dāng)天網(wǎng)絡(luò)抖動(dòng)，通過(guò)查看Kafka的消費(fèi)者超時(shí)配置為50ms，隨后，將消費(fèi)的時(shí)間修改為500ms后問(wèn)題解決。