Kafka中產(chǎn)生數(shù)據(jù)積壓的原因以及解決方案

1、kafka中數(shù)據(jù)積壓的原因

kafka作為消息隊(duì)列，其中數(shù)據(jù)積壓也是經(jīng)常遇到的問題之一。

我們都知道，數(shù)據(jù)積壓的直接原因，一定是系統(tǒng)中的某個(gè)部分出現(xiàn)了性能問題，來不及處理上游發(fā)送的數(shù)據(jù)，才會導(dǎo)致數(shù)據(jù)積壓。

那么我們就需要分析在使用kafka時(shí)，如何通過優(yōu)化代碼以及參數(shù)配置來最大程度的避免數(shù)據(jù)積壓來對業(yè)務(wù)中的影響。

2、kafka中數(shù)據(jù)積壓的解決方案

	首先我們在上面分析得出，是由于上游生產(chǎn)者producer發(fā)送數(shù)據(jù)過快，以及下游消費(fèi)者consumer拉取數(shù)據(jù)過慢，實(shí)質(zhì)上就是，生產(chǎn)者生產(chǎn)數(shù)據(jù)速度>>消費(fèi)者消費(fèi)數(shù)據(jù)速度。那么就可以把問題定位到生產(chǎn)者producer以及消費(fèi)者consumer這兩方面上。

1、生產(chǎn)者producer：吞吐量
	可以通過修改以下參數(shù)配置提提升生產(chǎn)者的吞吐量：
	
	1）batch.memory修改緩沖區(qū)大小
	
	設(shè)置發(fā)送消息的緩沖區(qū)，默認(rèn)值是33554432，就是32MB

	如果發(fā)送消息出去的速度小于寫入消息進(jìn)去的速度，就會導(dǎo)致緩沖區(qū)寫滿，此時(shí)生產(chǎn)消息就會阻塞住，所以說這里就應(yīng)該多做一些壓測，盡可能保證說這塊緩沖區(qū)不會被寫滿導(dǎo)致生產(chǎn)行為被阻塞住。
	
	2）compression.type壓縮格式
	
	默認(rèn)是none，不壓縮，但是也可以使用lz4壓縮，效率還是不錯(cuò)的，壓縮之后可以減小數(shù)據(jù)量，提升吞吐量，但是會加大producer端的cpu開銷。
	
	3）batch.size批次大小
	
	設(shè)置merge batch合并批次消息的大小
	
	如果 batch 批次太小，會導(dǎo)致頻繁網(wǎng)絡(luò)請求，吞吐量下降；

	如果batch批次太大，會導(dǎo)致一條消息需要等待很久才能被發(fā)送出去，而且會讓內(nèi)存緩沖區(qū)有很大壓力，過多數(shù)據(jù)緩沖在內(nèi)存里。

	默認(rèn)值是：16384，就是16kb，也就是一個(gè)batch批次滿了16kb就發(fā)送出去，一般在實(shí)際生產(chǎn)環(huán)境，這個(gè)batch批次的值可以增大一些來提升吞吐量，可以自己壓測一下。
	
	4）linger.ms等待時(shí)長
	
	這個(gè)值默認(rèn)是0，意思就是消息必須立即被發(fā)送，但是這是不對的。

	一般設(shè)置一個(gè)100毫秒之類的，這樣的話就是說，這個(gè)消息被發(fā)送出去后進(jìn)入一個(gè)batch批次，如果100毫秒內(nèi)，這個(gè)batch批次滿了16kb，自然就會發(fā)送出去。

	但是如果100毫秒內(nèi)，batch沒滿，那么也必須把消息發(fā)送出去了，不能讓消息的發(fā)送延遲時(shí)間太長，也避免給內(nèi)存造成過大的一個(gè)壓力。

2、消費(fèi)者consum	：擴(kuò)容，擴(kuò)分區(qū)；增加consumer

	1）提升消費(fèi)者組中的消費(fèi)者數(shù)以及Topic中的分區(qū)數(shù)，讓二者相等，假設(shè)設(shè)置為3個(gè)分區(qū) = 3CPU。
	
	2）提高消費(fèi)者拉取數(shù)據(jù)的能力，比如Flume每次拉取的數(shù)據(jù)可以由1000條改為3000條、Spark中將限流的參數(shù)增大、Flink中保證數(shù)據(jù)的處理效率等。

3、數(shù)據(jù)積壓分析V2.0

	日常系統(tǒng)正常運(yùn)轉(zhuǎn)的時(shí)候，沒有積壓或者只有少量積壓很快就消費(fèi)掉了，但是某一個(gè)時(shí)刻，突然就開始積壓消息并且積壓持續(xù)上漲。

	這種情況下需要你在短時(shí)間內(nèi)找到消息積壓的原因，迅速解決問題才不至于影響業(yè)務(wù)。

	導(dǎo)致突然積壓的原因肯定是多種多樣的，不同的系統(tǒng)、不同的情況有不同的原因，不能一概而論。

	但是，我們排查消息積壓原因，是有一些相對固定而且比較有效的方法的。

	能導(dǎo)致積壓突然增加，最粗粒度的原因，只有兩種：

	1、要么是發(fā)送變快了，2、要么是消費(fèi)變慢了。

	大部分消息隊(duì)列都內(nèi)置了監(jiān)控的功能，只要通過監(jiān)控?cái)?shù)據(jù)，很容易確定是哪種原因。

	如果是單位時(shí)間發(fā)送的消息增多，比如說是趕上大促或者搶購，短時(shí)間內(nèi)不太可能優(yōu)化消費(fèi)端的代碼來提升消費(fèi)性能，唯一的方法是通過擴(kuò)容消費(fèi)端的實(shí)例數(shù)來提升總體的消費(fèi)能力。

	如果短時(shí)間內(nèi)沒有足夠的服務(wù)器資源進(jìn)行擴(kuò)容，沒辦法的辦法是，將系統(tǒng)降級，通過關(guān)閉一些不重要的業(yè)務(wù)，減少發(fā)送方發(fā)送的數(shù)據(jù)量，最低限度讓系統(tǒng)還能正常運(yùn)轉(zhuǎn)，服務(wù)一些重要業(yè)務(wù)。

	還有一種不太常見的情況，你通過監(jiān)控發(fā)現(xiàn)，無論是發(fā)送消息的速度還是消費(fèi)消息的速度和原來都沒什么變化，這時(shí)候你需要檢查一下你的消費(fèi)端，是不是消費(fèi)失敗導(dǎo)致的一條消息反復(fù)消費(fèi)這種情況比較多，這種情況也會拖慢整個(gè)系統(tǒng)的消費(fèi)速度。

	如果監(jiān)控到消費(fèi)變慢了，你需要檢查你的消費(fèi)實(shí)例，分析一下是什么原因?qū)е孪M(fèi)變慢。

	優(yōu)先檢查一下日志是否有大量的消費(fèi)錯(cuò)誤，如果沒有錯(cuò)誤的話，可以通過打印堆棧信息，看一下你的消費(fèi)線程是不是卡在什么地方不動了，比如觸發(fā)了死鎖或者卡在等待某些資源上了。

文章來源地址http://www.zghlxwxcb.cn/news/detail-512178.html

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