一、Producer端消息優(yōu)化

Kafka支持使用異步批量的方式發(fā)送消息。當(dāng)Producer生產(chǎn)一條消息時(shí)，并不會(huì)立刻發(fā)送到Broker，而是先放入到消息緩沖區(qū)，等到緩沖區(qū)滿或者消息個(gè)數(shù)達(dá)到限制后，再批量發(fā)送到Broker。Producer端需要注意以下參數(shù)：

• acks參數(shù)：**表示Producer發(fā)送消息后是否需要等待broker的應(yīng)答。目前提供三個(gè)取值，acks=0 表示發(fā)送消息后立即返回，不需要等待broker的確認(rèn)；acks=1 表示消息被寫入到主分區(qū)后，broker需給予應(yīng)答，此時(shí)并不保證已寫入kafka的復(fù)制分區(qū)，如果主分區(qū)掛掉，消息可能會(huì)丟失；acks=-1 是最嚴(yán)格的確認(rèn)，必須等到消息寫入到主分區(qū)并且同步復(fù)制分區(qū)成功后才會(huì)應(yīng)答。
• buffer.memory參數(shù)：表示消息緩存區(qū)的大小，單位是字節(jié)。
• batch.size參數(shù)：batch的閾值。當(dāng)kafka采用異步方式發(fā)送消息時(shí)，默認(rèn)是按照batch模式發(fā)送。其中同一主題同一分區(qū)的消息會(huì)默認(rèn)合并到一個(gè)batch內(nèi)，當(dāng)達(dá)到閾值后就會(huì)發(fā)送。
• linger.ms參數(shù)：這個(gè)是設(shè)置消息發(fā)送延遲，這樣可以收集更多的消息后批量發(fā)送，默認(rèn)大小是0ms（就是有消息就立即發(fā)送）。

通過上述參數(shù)可以做可靠性、時(shí)延和吞吐量之間的權(quán)衡。如果業(yè)務(wù)對(duì)消息丟失有一定容忍，對(duì)時(shí)延要求不高，例如點(diǎn)擊率統(tǒng)計(jì)，可以設(shè)置較大的batch.size，較長(zhǎng)的linger.ms，并且設(shè)置acks=0，這樣可以達(dá)到很高的吞吐率。

二、磁盤順序讀寫

Kafka本質(zhì)上是基于磁盤存儲(chǔ)的消息隊(duì)列，雖然在我們固有印象中磁盤的讀寫速度是非常慢的，但是Kafka巧妙利用了操作系統(tǒng)對(duì)IO的優(yōu)化策略，達(dá)到了和內(nèi)存讀寫近似的效果。這種優(yōu)化策略就是磁盤緩存（Page Cache）。Page Cache可以看作磁盤文件在物理內(nèi)存中的映射，根據(jù)局部性原理，如果某塊數(shù)據(jù)被用到，那么存儲(chǔ)在它周圍的數(shù)據(jù)也很可能即將被用到。操作系統(tǒng)可以采用預(yù)讀和后寫的方式，對(duì)磁盤讀寫進(jìn)行優(yōu)化。

• 預(yù)讀：磁盤順序讀取的效率是很高的（不需要尋道時(shí)間，只需要很少的旋轉(zhuǎn)時(shí)間）。而在讀取磁盤某塊數(shù)據(jù)時(shí)，同時(shí)會(huì)順序讀取相鄰地址的數(shù)據(jù)加載到PageCache，這樣在讀取后續(xù)連續(xù)數(shù)據(jù)時(shí)，只需要從PageCache中讀取數(shù)據(jù)，相當(dāng)于內(nèi)存讀寫，速度會(huì)特別快。
• 后寫：數(shù)據(jù)并不是直接寫入到磁盤，而是默認(rèn)先寫入到Page Cache，再由Page Cache刷新到磁盤，刷新頻率是由操作系統(tǒng)周期性的sync觸發(fā)的（用戶也可以手動(dòng)調(diào)用sync觸發(fā)刷新操作）。后寫的方式大大減少對(duì)磁盤的總寫入次數(shù)，提高寫入效率。

Kafka中的消息存儲(chǔ)在partition中，每個(gè)partition對(duì)應(yīng)一組物理空間連續(xù)的磁盤文件。當(dāng)有新消息進(jìn)來時(shí)，會(huì)以追加的方式寫入到磁盤文件末尾。消費(fèi)者拉取消息時(shí)，也是以partition為單位，順序拉取數(shù)據(jù)消費(fèi)。可以看出來Kafka的讀寫都是順序的，可以很高效地利用PageCache，解決磁盤讀寫的性能問題。

三、零拷貝技術(shù)

零拷貝技術(shù)一種是對(duì)IO的進(jìn)一步優(yōu)化，它的原理是通過減少數(shù)據(jù)在內(nèi)存中的拷貝次數(shù)，來提高IO性能。從Broker的角度考慮，Kafka的消費(fèi)對(duì)應(yīng)是從磁盤文件讀取數(shù)據(jù)發(fā)送到網(wǎng)卡的過程，介紹零拷貝之前，我們先看如果用傳統(tǒng)IO，這個(gè)過程是怎么實(shí)現(xiàn)的：

• 應(yīng)用進(jìn)程使用系統(tǒng)調(diào)用read()，從用戶態(tài)切換到內(nèi)核態(tài)；
• 操作系統(tǒng)委托DMA（Direct Memory Access 存儲(chǔ)器直接訪問）將硬盤數(shù)據(jù)copy到內(nèi)核緩沖區(qū)（DMA copy）；
• read()返回，內(nèi)核緩存區(qū)數(shù)據(jù)拷貝到用戶緩沖區(qū)（CPU copy），同時(shí)進(jìn)程從內(nèi)核態(tài)切換到用戶態(tài)；
• 應(yīng)用進(jìn)程取到數(shù)據(jù)后，進(jìn)行系統(tǒng)調(diào)用write()，再次從用戶態(tài)切換到內(nèi)核態(tài)；
• 數(shù)據(jù)從用戶緩沖區(qū)拷貝到socket緩沖區(qū)（CPU copy）；
• 操作系統(tǒng)委托DMA將socket緩沖區(qū)數(shù)據(jù)寫入到網(wǎng)卡（DMA copy）；
• write()方法返回，進(jìn)程從內(nèi)核態(tài)切換到用戶態(tài)，整個(gè)流程結(jié)束。

傳統(tǒng)過程主要依賴于read/write系統(tǒng)調(diào)用，一共需要4次上下文切換，2次CPU copy，2次DMA copy，其中上下文切換和CPU copy都要消耗大量系統(tǒng)資源（DMA copy無需CPU介入，相對(duì)不消耗資源）。那能否優(yōu)化這個(gè)過程？

Kafka使用sendfile的系統(tǒng)調(diào)用代替?zhèn)鹘y(tǒng)的read/write系統(tǒng)調(diào)用。sendfile是非常典型的零拷貝技術(shù)，我們?cè)倏磗endfile是怎么實(shí)現(xiàn)磁盤文件讀取數(shù)據(jù)發(fā)送到網(wǎng)卡的這個(gè)過程：

• 應(yīng)用進(jìn)程進(jìn)行系統(tǒng)調(diào)用sendfile，從用戶態(tài)進(jìn)入內(nèi)核態(tài)；
• 操作系統(tǒng)委托DMA將硬盤數(shù)據(jù)拷貝到內(nèi)核緩沖區(qū)（DMA copy）；
• 操作系統(tǒng)將文件描述符和數(shù)據(jù)長(zhǎng)度發(fā)送到socket緩沖區(qū)，同時(shí)委托DMA拷貝數(shù)據(jù)，直接從內(nèi)核緩沖區(qū)將數(shù)據(jù)寫入到網(wǎng)卡；
• sendfile方法返回，進(jìn)程從內(nèi)核態(tài)切換到用戶態(tài)，流程結(jié)束。

可見使用sendfile流程后，一共只需要兩次上下文切換，0次CPU copy，性能上的提升很明顯。

四、End-To-End的壓縮方式

在帶寬受限的情況下，吞吐量和消息的大小呈反比關(guān)系，所以壓縮消息能顯著提升吞吐量。Kafka支持多種壓縮算法，例如GZIP、Snappy和LZ4和Zstd。同時(shí)Kafka支持End-To-End的壓縮方式，消息在生產(chǎn)端被壓縮，Broker端默認(rèn)不解壓，直接存儲(chǔ)到磁盤，直到消費(fèi)端才被解壓，這種方式保證了消息在網(wǎng)絡(luò)傳輸過程中一直是被壓縮的狀態(tài)。

總結(jié)

以上是生活随笔為你收集整理的Kafka的高吞吐率是怎么实现的的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。