Kafka為何要設(shè)計(jì)緩沖池機(jī)制？初看一臉懵逼，看懂直接跪下

作者：石杉的架構(gòu)筆記 2022-09-23 18:16:25

云計(jì)算

Kafka 我們通過Kafka內(nèi)核源碼中的一些設(shè)計(jì)思想，來看你設(shè)計(jì)Kafka架構(gòu)的技術(shù)大牛，是怎么優(yōu)化JVM的GC問題的？

創(chuàng)新互聯(lián)是一家專業(yè)提供肇源企業(yè)網(wǎng)站建設(shè),專注與成都做網(wǎng)站、成都網(wǎng)站建設(shè)、HTML5、小程序制作等業(yè)務(wù)。10年已為肇源眾多企業(yè)、政府機(jī)構(gòu)等服務(wù)。創(chuàng)新互聯(lián)專業(yè)網(wǎng)站制作公司優(yōu)惠進(jìn)行中。

這篇文章，同樣給大家聊一個(gè)硬核的技術(shù)知識，我們通過Kafka內(nèi)核源碼中的一些設(shè)計(jì)思想，來看你設(shè)計(jì)Kafka架構(gòu)的技術(shù)大牛，是怎么優(yōu)化JVM的GC問題的？

1、Kafka的客戶端緩沖機(jī)制

首先，先得給大家明確一個(gè)事情，那就是在客戶端發(fā)送消息給kafka服務(wù)器的時(shí)候，一定是有一個(gè)內(nèi)存緩沖機(jī)制的。

也就是說，消息會先寫入一個(gè)內(nèi)存緩沖中，然后直到多條消息組成了一個(gè)Batch，才會一次網(wǎng)絡(luò)通信把Batch發(fā)送過去。

整個(gè)過程如下圖所示：

2、內(nèi)存緩沖造成的頻繁GC問題

那么這種內(nèi)存緩沖機(jī)制的本意，其實(shí)就是把多條消息組成一個(gè)Batch，一次網(wǎng)絡(luò)請求就是一個(gè)Batch或者多個(gè)Batch。

這樣每次網(wǎng)絡(luò)請求都可以發(fā)送很多數(shù)據(jù)過去，避免了一條消息一次網(wǎng)絡(luò)請求。從而提升了吞吐量，即單位時(shí)間內(nèi)發(fā)送的數(shù)據(jù)量。

但是問題來了，大家可以思考一下，一個(gè)Batch中的數(shù)據(jù)，會取出來然后封裝在底層的網(wǎng)絡(luò)包里，通過網(wǎng)絡(luò)發(fā)送出去到達(dá)Kafka服務(wù)器。

那么然后呢？這個(gè)Batch里的數(shù)據(jù)都發(fā)送過去了，現(xiàn)在Batch里的數(shù)據(jù)應(yīng)該怎么處理？

你要知道，這些Batch里的數(shù)據(jù)此時(shí)可還在客戶端的JVM的內(nèi)存里??！那么此時(shí)從代碼實(shí)現(xiàn)層面，一定會嘗試避免任何變量去引用這些Batch對應(yīng)的數(shù)據(jù)，然后嘗試觸發(fā)JVM自動(dòng)回收掉這些內(nèi)存垃圾。

這樣不斷的讓JVM回收垃圾，就可以不斷的清理掉已經(jīng)發(fā)送成功的Batch了，然后就可以不斷的騰出來新的內(nèi)存空間讓后面新的數(shù)據(jù)來使用。

這種想法很好，但是實(shí)際線上運(yùn)行的時(shí)候一定會有問題，最大的問題，就是JVM GC問題。

大家都知道一點(diǎn)，JVM GC在回收內(nèi)存垃圾的時(shí)候，他會有一個(gè)“Stop the World”的過程，也就是垃圾回收線程運(yùn)行的時(shí)候，會導(dǎo)致其他工作線程短暫的停頓，這樣可以便于他自己安安靜靜的回收內(nèi)存垃圾。

這個(gè)也很容易想明白，畢竟你要是在回收內(nèi)存垃圾的時(shí)候，你的工作線程還在不斷的往內(nèi)存里寫數(shù)據(jù)，制造更多的內(nèi)存垃圾，那你讓人家JVM怎么回收垃圾？

這就好比在大馬路上，如果地上有很多垃圾，現(xiàn)在要把垃圾都掃干凈，最好的辦法是什么？大家都讓開，把馬路空出來，然后清潔工就是把垃圾清理干凈。

但是如果清潔工在清掃垃圾的時(shí)候，結(jié)果一幫人在旁邊不停的嗑瓜子扔瓜子殼，吃西瓜扔西瓜皮，不停的制造垃圾，你覺得清潔工內(nèi)心啥感受？當(dāng)然是很憤慨了，照這么搞，地上的垃圾永遠(yuǎn)的都搞不干凈了！

通過了上面的語言描述，我們再來一張圖，大家看看就更加清楚了。

現(xiàn)在JVM GC是越來越先進(jìn)，從CMS垃圾回收器到G1垃圾回收器，核心的目標(biāo)之一就是不斷的縮減垃圾回收的時(shí)候，導(dǎo)致其他工作線程停頓的時(shí)間。

所以現(xiàn)在越是新款的垃圾回收器導(dǎo)致工作線程停頓的時(shí)間越短，但是再怎么短，他也還是存在?。?/p>

所以說，如何盡可能在自己的設(shè)計(jì)上避免JVM頻繁的GC就是一個(gè)非常考驗(yàn)水平的事兒了。

3、Kafka設(shè)計(jì)者實(shí)現(xiàn)的緩沖池機(jī)制

在Kafka客戶端內(nèi)部，對這個(gè)問題實(shí)現(xiàn)了一個(gè)非常優(yōu)秀的機(jī)制，就是緩沖池的機(jī)制

簡單來說，就是每個(gè)Batch底層都對應(yīng)一塊內(nèi)存空間，這個(gè)內(nèi)存空間就是專門用來存放寫入進(jìn)去的消息的。

然后呢，當(dāng)一個(gè)Batch被發(fā)送到了kafka服務(wù)器，這個(gè)Batch的數(shù)據(jù)不再需要了，就意味著這個(gè)Batch的內(nèi)存空間不再使用了。

此時(shí)這個(gè)Batch底層的內(nèi)存空間不要交給JVM去垃圾回收，而是把這塊內(nèi)存空間給放入一個(gè)緩沖池里。

這個(gè)緩沖池里放了很多塊內(nèi)存空間，下次如果你又有一個(gè)新的Batch了，那么不就可以直接從這個(gè)緩沖池里獲取一塊內(nèi)存空間就ok了？

然后如果一個(gè)Batch發(fā)送出去了之后，再把內(nèi)存空間給人家還回來不就好了？以此類推，循環(huán)往復(fù)。

同樣，聽完了上面的文字描述，再來一張圖，看完這張圖相信大伙兒就明白了：

一旦使用了這個(gè)緩沖池機(jī)制之后，就不涉及到頻繁的大量內(nèi)存的GC問題了。

為什么呢？因?yàn)樗梢陨蟻砭驼加霉潭ǖ膬?nèi)存，比如32MB。然后把32MB劃分為N多個(gè)內(nèi)存塊，比如說一個(gè)內(nèi)存塊是16KB，這樣的話這個(gè)緩沖池里就會有很多的內(nèi)存塊。

然后你需要?jiǎng)?chuàng)建一個(gè)新的Batch，就從緩沖池里取一個(gè)16KB的內(nèi)存塊就可以了，然后這個(gè)Batch就不斷的寫入消息，但是最多就是寫16KB，因?yàn)锽atch底層的內(nèi)存塊就16KB。

接著如果Batch被發(fā)送到Kafka服務(wù)器了，此時(shí)Batch底層的內(nèi)存塊就直接還回緩沖池就可以了。

下次別人再要構(gòu)建一個(gè)Batch的時(shí)候，再次使用緩沖池里的內(nèi)存塊就好了。這樣就可以利用有限的內(nèi)存，對他不停的反復(fù)重復(fù)的利用。因?yàn)槿绻愕腂atch使用完了以后是把內(nèi)存塊還回到緩沖池中去，那么就不涉及到垃圾回收了。

如果沒有頻繁的垃圾回收，自然就避免了頻繁導(dǎo)致的工作線程的停頓了，JVM GC問題是不是就得到了大幅度的優(yōu)化？

沒錯(cuò)，正是這個(gè)設(shè)計(jì)思想讓Kafka客戶端的性能和吞吐量都非常的高，這里蘊(yùn)含了大量的優(yōu)秀的機(jī)制。

那么此時(shí)有人說了，如果我現(xiàn)在把一個(gè)緩沖池里的內(nèi)存資源都占滿了，現(xiàn)在緩沖池里暫時(shí)沒有內(nèi)存塊了，怎么辦呢？

很簡單，阻塞你的寫入操作，不讓你繼續(xù)寫入消息了。把你給阻塞住，不停的等待，直到有內(nèi)存塊釋放出來，然后再繼續(xù)讓你寫入消息。

4、總結(jié)一下

這篇文章我們從Kafka內(nèi)存緩沖機(jī)制的設(shè)計(jì)思路開始，一直分析到了JVM GC問題的產(chǎn)生原因以及惡劣的影響。

接著談到了Kafka優(yōu)秀的緩沖池機(jī)制的設(shè)計(jì)思想以及他是如何解決這個(gè)問題的，分析了很多Kafka作者在設(shè)計(jì)的時(shí)候展現(xiàn)出的優(yōu)秀的技術(shù)設(shè)計(jì)思想和能力。

希望大家多吸取這里的精華，在以后面試或者工作的時(shí)候，可以把這些優(yōu)秀的思想納為己用。

文章題目：Kafka為何要設(shè)計(jì)緩沖池機(jī)制？初看一臉懵逼，看懂直接跪下
文章出自：http://m.fisionsoft.com.cn/article/coejhgg.html