Kafka集群消息積壓問題及怎么樣處理

今天就跟大家聊聊有關(guān)Kafka集群消息積壓問題及怎么樣處理，可能很多人都不太了解，為了讓大家更加了解，小編給大家總結(jié)了以下內(nèi)容，希望大家根據(jù)這篇文章可以有所收獲。

通常情況下，企業(yè)中會(huì)采取輪詢或者隨機(jī)的方式，通過Kafka的producer向Kafka集群生產(chǎn)數(shù)據(jù)，來盡可能保證Kafk分區(qū)之間的數(shù)據(jù)是均勻分布的。

在分區(qū)數(shù)據(jù)均勻分布的前提下，如果我們針對(duì)要處理的topic數(shù)據(jù)量等因素，設(shè)計(jì)出合理的Kafka分區(qū)數(shù)量。對(duì)于一些實(shí)時(shí)任務(wù)，比如Spark Streaming/Structured-Streaming、Flink和Kafka集成的應(yīng)用，消費(fèi)端不存在長時(shí)間"掛掉"的情況即數(shù)據(jù)一直在持續(xù)被消費(fèi)，那么一般不會(huì)產(chǎn)生Kafka數(shù)據(jù)積壓的情況。

Kafka消息積壓的典型場景：

比如，我們寫的實(shí)時(shí)應(yīng)用因?yàn)槟撤N原因掛掉了，并且這個(gè)任務(wù)沒有被監(jiān)控程序監(jiān)控發(fā)現(xiàn)通知相關(guān)負(fù)責(zé)人，負(fù)責(zé)人又沒有寫自動(dòng)拉起任務(wù)的腳本進(jìn)行重啟。

Kafka單分區(qū)生產(chǎn)消息的速度qps通常很高，如果消費(fèi)者因?yàn)槟承┰颍ū热缡軜I(yè)務(wù)邏輯復(fù)雜度影響，消費(fèi)時(shí)間會(huì)有所不同），就會(huì)出現(xiàn)消費(fèi)滯后的情況。

那么，針對(duì)上述的情況，有什么好的辦法處理數(shù)據(jù)積壓呢？

一般情況下，針對(duì)性的解決辦法有以下幾種：

a.任務(wù)重新啟動(dòng)后直接消費(fèi)最新的消息，對(duì)于"滯后"的歷史數(shù)據(jù)采用離線程序進(jìn)行"補(bǔ)漏"。

此外，建議將任務(wù)納入監(jiān)控體系，當(dāng)任務(wù)出現(xiàn)問題時(shí)，及時(shí)通知相關(guān)負(fù)責(zé)人處理。當(dāng)然任務(wù)重啟腳本也是要有的，還要求實(shí)時(shí)框架異常處理能力要強(qiáng)，避免數(shù)據(jù)不規(guī)范導(dǎo)致的不能重新拉起任務(wù)。

b.任務(wù)啟動(dòng)從上次提交offset處開始消費(fèi)處理

看完上述內(nèi)容，你們對(duì)Kafka集群消息積壓問題及怎么樣處理有進(jìn)一步的了解嗎？如果還想了解更多知識(shí)或者相關(guān)內(nèi)容，請關(guān)注億速云行業(yè)資訊頻道，感謝大家的支持。