溫馨提示×

您好,登錄后才能下訂單哦!

密碼登錄×
登錄注冊(cè)×
其他方式登錄
點(diǎn)擊 登錄注冊(cè) 即表示同意《億速云用戶(hù)服務(wù)條款》

如何解析Kafka性能優(yōu)化

發(fā)布時(shí)間:2021-12-15 10:23:36 來(lái)源:億速云 閱讀:142 作者:柒染 欄目:云計(jì)算

這期內(nèi)容當(dāng)中小編將會(huì)給大家?guī)?lái)有關(guān)如何解析Kafka性能優(yōu)化,文章內(nèi)容豐富且以專(zhuān)業(yè)的角度為大家分析和敘述,閱讀完這篇文章希望大家可以有所收獲。

Kafka在提高效率方面做了很大努力。Kafka的一個(gè)主要使用場(chǎng)景是處理網(wǎng)站活動(dòng)日志,吞吐量是非常大的,每個(gè)頁(yè)面都會(huì)產(chǎn)生好多次寫(xiě)操作。讀方面,假設(shè)每個(gè)消息只被消費(fèi)一次,讀的量的也是很大的,Kafka也盡量使讀的操作更輕量化。

我們之前討論了磁盤(pán)的性能問(wèn)題,線性讀寫(xiě)的情況下影響磁盤(pán)性能問(wèn)題大約有兩個(gè)方面:太多的瑣碎的I/O操作和太多的字節(jié)拷貝。I/O問(wèn)題發(fā)生在客戶(hù)端和服務(wù)端之間,也發(fā)生在服務(wù)端內(nèi)部的持久化的操作中。
消息集(message set)
為了避免這些問(wèn)題,Kafka建立了“消息集(message set)”的概念,將消息組織到一起,作為處理的單位。以消息集為單位處理消息,比以單個(gè)的消息為單位處理,會(huì)提升不少性能。Producer把消息集一塊發(fā)送給服務(wù)端,而不是一條條的發(fā)送;服務(wù)端把消息集一次性的追加到日志文件中,這樣減少了瑣碎的I/O操作。consumer也可以一次性的請(qǐng)求一個(gè)消息集。
另外一個(gè)性能優(yōu)化是在字節(jié)拷貝方面。在低負(fù)載的情況下這不是問(wèn)題,但是在高負(fù)載的情況下它的影響還是很大的。為了避免這個(gè)問(wèn)題,Kafka使用了標(biāo)準(zhǔn)的二進(jìn)制消息格式,這個(gè)格式可以在producer,broker和producer之間共享而無(wú)需做任何改動(dòng)。
zero copy
Broker維護(hù)的消息日志僅僅是一些目錄文件,消息集以固定隊(duì)的格式寫(xiě)入到日志文件中,這個(gè)格式producer和consumer是共享的,這使得Kafka可以一個(gè)很重要的點(diǎn)進(jìn)行優(yōu)化:消息在網(wǎng)絡(luò)上的傳遞?,F(xiàn)代的unix操作系統(tǒng)提供了高性能的將數(shù)據(jù)從頁(yè)面緩存發(fā)送到socket的系統(tǒng)函數(shù),在linux中,這個(gè)函數(shù)是sendfile.
為了更好的理解sendfile的好處,我們先來(lái)看下一般將數(shù)據(jù)從文件發(fā)送到socket的數(shù)據(jù)流向:

  1.  操作系統(tǒng)把數(shù)據(jù)從文件拷貝內(nèi)核中的頁(yè)緩存中

  2. 應(yīng)用程序從頁(yè)緩存從把數(shù)據(jù)拷貝自己的內(nèi)存緩存中

  3. 應(yīng)用程序?qū)?shù)據(jù)寫(xiě)入到內(nèi)核中socket緩存中

  4.  操作系統(tǒng)把數(shù)據(jù)從socket緩存中拷貝到網(wǎng)卡接口緩存,從這里發(fā)送到網(wǎng)絡(luò)上。


這顯然是低效率的,有4次拷貝和2次系統(tǒng)調(diào)用。Sendfile通過(guò)直接將數(shù)據(jù)從頁(yè)面緩存發(fā)送網(wǎng)卡接口緩存,避免了重復(fù)拷貝,大大的優(yōu)化了性能。
在一個(gè)多consumers的場(chǎng)景里,數(shù)據(jù)僅僅被拷貝到頁(yè)面緩存一次而不是每次消費(fèi)消息的時(shí)候都重復(fù)的進(jìn)行拷貝。這使得消息以近乎網(wǎng)絡(luò)帶寬的速率發(fā)送出去。這樣在磁盤(pán)層面你幾乎看不到任何的讀操作,因?yàn)閿?shù)據(jù)都是從頁(yè)面緩存中直接發(fā)送到網(wǎng)絡(luò)上去了。
這篇文章詳細(xì)介紹了sendfile和zero-copy技術(shù)在Java方面的應(yīng)用。
數(shù)據(jù)壓縮
很多時(shí)候,性能的瓶頸并非CPU或者硬盤(pán)而是網(wǎng)絡(luò)帶寬,對(duì)于需要在數(shù)據(jù)中心之間傳送大量數(shù)據(jù)的應(yīng)用更是如此。當(dāng)然用戶(hù)可以在沒(méi)有Kafka支持的情況下各自壓縮自己的消息,但是這將導(dǎo)致較低的壓縮率,因?yàn)橄啾扔趯⑾为?dú)壓縮,將大量文件壓縮在一起才能起到最好的壓縮效果。
Kafka采用了端到端的壓縮:因?yàn)橛小跋⒓钡母拍?,客?hù)端的消息可以一起被壓縮后送到服務(wù)端,并以壓縮后的格式寫(xiě)入日志文件,以壓縮的格式發(fā)送到consumer,消息從producer發(fā)出到consumer拿到都被是壓縮的,只有在consumer使用的時(shí)候才被解壓縮,所以叫做“端到端的壓縮”。
Kafka支持GZIP和Snappy壓縮協(xié)議。

上述就是小編為大家分享的如何解析Kafka性能優(yōu)化了,如果剛好有類(lèi)似的疑惑,不妨參照上述分析進(jìn)行理解。如果想知道更多相關(guān)知識(shí),歡迎關(guān)注億速云行業(yè)資訊頻道。

向AI問(wèn)一下細(xì)節(jié)

免責(zé)聲明:本站發(fā)布的內(nèi)容(圖片、視頻和文字)以原創(chuàng)、轉(zhuǎn)載和分享為主,文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng),如果涉及侵權(quán)請(qǐng)聯(lián)系站長(zhǎng)郵箱:is@yisu.com進(jìn)行舉報(bào),并提供相關(guān)證據(jù),一經(jīng)查實(shí),將立刻刪除涉嫌侵權(quán)內(nèi)容。

AI