Kafka為了追求極致的性能，有這11大優(yōu)化之處

作者：阿飛的BLOG 2019-07-23 09:20:15

開源

Kafka Kafka在性能優(yōu)化方面做了哪些舉措，這是Kafka面試的時候的常見問題，面試官問你這個問題也不算刁難你。

Kafka在性能優(yōu)化方面做了哪些舉措，這是Kafka面試的時候的常見問題，面試官問你這個問題也不算刁難你。在網(wǎng)上也有很多相關(guān)的文章開講解這個問題，比如之前各大公眾號轉(zhuǎn)載的“為什么Kafka這么快?”，這些文章我看了，寫的不錯，問題在于只是羅列了部分的要領(lǐng)，沒有全部的詳述出來。本文所羅列的要領(lǐng)會比你們網(wǎng)上搜尋到的都多，如果你在看完本篇文章之后，在面試的時候遇到相關(guān)問題，相信你一定能讓面試官眼前一亮。

批量處理

傳統(tǒng)消息中間件的消息發(fā)送和消費整體上是針對單條的。對于生產(chǎn)者而言，它先發(fā)一條消息，然后broker返回ACK表示已接收，這里產(chǎn)生2次rpc;對于消費者而言，它先請求接受消息，然后broker返回消息，最后發(fā)送ACK表示已消費，這里產(chǎn)生了3次rpc(有些消息中間件會優(yōu)化一下，broker返回的時候返回多條消息)。而Kafka采用了批量處理：生產(chǎn)者聚合了一批消息，然后再做2次rpc將消息存入broker，這原本是需要很多次的rpc才能完成的操作。假設(shè)需要發(fā)送1000條消息，每條消息大小1KB，那么傳統(tǒng)的消息中間件需要2000次rpc，而Kafka可能會把這1000條消息包裝成1個1MB的消息，采用2次rpc就完成了任務(wù)。這一改進舉措一度被認為是一種“作弊”的行為，然而在微批次理念盛行的今日，其它消息中間件也開始紛紛效仿。

客戶端優(yōu)化

這里接著批量處理的概念繼續(xù)來說，新版生產(chǎn)者客戶端摒棄了以往的單線程，而采用了雙線程：主線程和Sender線程。主線程負責將消息置入客戶端緩存，Sender線程負責從緩存中發(fā)送消息，而這個緩存會聚合多個消息為一個批次。有些消息中間件會把消息直接扔到broker。

日志格式

Kafka從0.8版本開始日志格式歷經(jīng)了三次變革：v0、v1、v2。 

日志編碼

如果了解了Kafka具體的日志格式(可以參考上圖)，那么你應(yīng)該了解日志(Record，或者稱之為消息)本身除了基本的key和value之外，還有一些其它的字段，原本這些附加字段按照固定的大小占用一定的篇幅(參考上圖左)，而Kafka最新的版本中采用了變長字段Varints和ZigZag編碼，有效地降低了這些附加字段的占用大小。日志(消息)盡可能變小了，那么網(wǎng)絡(luò)傳輸?shù)男室矔兏?，日志存盤的效率也會提升，從而整理的性能也會有所提升。

消息壓縮

Kafka支持多種消息壓縮方式(gzip、snappy、lz4)。對消息進行壓縮可以極大地減少網(wǎng)絡(luò)傳輸 量、降低網(wǎng)絡(luò) I/O，從而提高整體的性能。消息壓縮是一種使用時間換空間的優(yōu)化方式，如果對時延有一定的要求，則不推薦對消息進行壓縮。

建立索引

每個日志分段文件對應(yīng)了兩個索引文件，主要用來提高查找消息的效率，這也是提升性能的一種方式(具體的內(nèi)容在書中的第5章有詳細的講解)。

分區(qū)

很多人會忽略掉這個因素，其實分區(qū)也是提升性能的一種非常有效的方式，這種方式所帶來的效果會比前面所說的日志編碼、消息壓縮等更加的明顯。分區(qū)在其他分布式組件中也有大量涉及，至于為什么分區(qū)能夠提升性能這種基本知識在這里就不在贅述了。不過需要注意，一昧地增加分區(qū)并不能一直帶來性能的提升，有興趣的同學可以看一下這篇《Kafka主題中的分區(qū)數(shù)越多吞吐量就越高?》。

一致性

絕大多數(shù)的資料在講述Kafka性能優(yōu)化的舉措之時是不會提及一致性的東西的。我們所了解的通用的一致性協(xié)議如Paxos、Raft、Gossip等，而Kafka另辟蹊徑采用類似Pacific-A的做法不是“拍大腿”拍出來的，采用這種模型會提升整理的效率。具體的細節(jié)后面會整理一篇，類似《在Kafka中使用Raft替換Pacific-A的可行性分析及優(yōu)缺點》。

順序?qū)懕P

操作系統(tǒng)可以針對線性讀寫做深層次的優(yōu)化，比如預(yù)讀(read-ahead，提前將一個比較大的磁盤塊讀入內(nèi)存) 和后寫(write-behind，將很多小的邏輯寫操作合并起來組成一個大的物理寫操作)技術(shù)。Kafka 在設(shè)計時采用了文件追加的方式來寫入消息，即只能在日志文件的尾部追加新的消息，并且也不允許修改已寫入的消息，這種方式屬于典型的順序?qū)懕P的操作，所以就算 Kafka 使用磁盤作為存儲介質(zhì)，它所能承載的吞吐量也不容小覷。

頁緩存

為什么Kafka性能這么高?當遇到這個問題的時候很多人都會想到上面的順序?qū)懕P這一點。其實在順序?qū)懕P前面還有頁緩存(PageCache)這一層的優(yōu)化。

頁緩存是操作系統(tǒng)實現(xiàn)的一種主要的磁盤緩存，以此用來減少對磁盤 I/O 的操作。具體來說，就是把磁盤中的數(shù)據(jù)緩存到內(nèi)存中，把對磁盤的訪問變?yōu)閷?nèi)存的訪問。為了彌補性 能上的差異，現(xiàn)代操作系統(tǒng)越來越“激進地”將內(nèi)存作為磁盤緩存，甚至會非常樂意將所有可用的內(nèi)存用作磁盤緩存，這樣當內(nèi)存回收時也幾乎沒有性能損失，所有對于磁盤的讀寫也 將經(jīng)由統(tǒng)一的緩存。

當一個進程準備讀取磁盤上的文件內(nèi)容時，操作系統(tǒng)會先查看待讀取的數(shù)據(jù)所在的頁 (page)是否在頁緩存(pagecache)中，如果存在(命中)則直接返回數(shù)據(jù)，從而避免了對物理磁盤的 I/O 操作;如果沒有命中，則操作系統(tǒng)會向磁盤發(fā)起讀取請求并將讀取的數(shù)據(jù)頁存入頁緩存，之后再將數(shù)據(jù)返回給進程。同樣，如果一個進程需要將數(shù)據(jù)寫入磁盤，那么操作系統(tǒng)也會檢測數(shù)據(jù)對應(yīng)的頁是否在頁緩存中，如果不存在，則會先在頁緩存中添加相應(yīng)的頁，最后將數(shù)據(jù)寫入對應(yīng)的頁。被修改過后的頁也就變成了臟頁，操作系統(tǒng)會在合適的時間把臟頁中的數(shù)據(jù)寫入磁盤，以保持數(shù)據(jù)的一致性。

對一個進程而言，它會在進程內(nèi)部緩存處理所需的數(shù)據(jù)，然而這些數(shù)據(jù)有可能還緩存在操作系統(tǒng)的頁緩存中，因此同一份數(shù)據(jù)有可能被緩存了兩次。并且，除非使用 Direct I/O 的方式， 否則頁緩存很難被禁止。此外，用過 Java 的人一般都知道兩點事實:對象的內(nèi)存開銷非常大， 通常會是真實數(shù)據(jù)大小的幾倍甚至更多，空間使用率低下; Java 的垃圾回收會隨著堆內(nèi)數(shù)據(jù)的增多而變得越來越慢?；谶@些因素，使用文件系統(tǒng)并依賴于頁緩存的做法明顯要優(yōu)于維護一 個進程內(nèi)緩存或其他結(jié)構(gòu)，至少我們可以省去了一份進程內(nèi)部的緩存消耗，同時還可以通過結(jié)構(gòu)緊湊的字節(jié)碼來替代使用對象的方式以節(jié)省更多的空間。如此，我們可以在 32GB 的機器上使用 28GB 至 30GB 的內(nèi)存而不用擔心 GC 所帶來的性能問題。此外，即使 Kafka 服務(wù)重啟， 頁緩存還是會保持有效，然而進程內(nèi)的緩存卻需要重建。這樣也極大地簡化了代碼邏輯，因為 維護頁緩存和文件之間的一致性交由操作系統(tǒng)來負責，這樣會比進程內(nèi)維護更加安全有效。

Kafka 中大量使用了頁緩存，這是 Kafka 實現(xiàn)高吞吐的重要因素之一。雖然消息都是先被寫入頁緩存，然后由操作系統(tǒng)負責具體的刷盤任務(wù)的。

零拷貝

我在很久之前就之前就發(fā)過一篇《什么是Zero Copy》,如果對Zero Copy不了解的同學可以翻閱一下。Kafka使用了Zero Copy技術(shù)提升了消費的效率。前面所說的Kafka將消息先寫入頁緩存，如果消費者在讀取消息的時候如果在頁緩存中可以命中，那么可以直接從頁緩存中讀取，這樣又節(jié)省了一次從磁盤到頁緩存的copy開銷。另外對于讀寫的概念可以進一步了解一下什么是寫放大和讀放大。

附

一個磁盤IO流程可以參考下圖： 

具體解析參考《Linux IO磁盤篇整理小記》。

寫在最后

本文羅列的這些Kafka的在性能優(yōu)化方面的要領(lǐng)，是你在面試碰到kafka相關(guān)問題時，展現(xiàn)自己牛逼的資本。不可不學，不可不掌握喲

文章標題：Kafka為了追求極致的性能，有這11大優(yōu)化之處
本文路徑：http://www.5511xx.com/article/ccosods.html