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

[[271473]]

批量處理

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

客戶端優(yōu)化

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

日志格式

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

日志編碼

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

消息壓縮

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

建立索引

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

分區(qū)

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

一致性

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

順序?qū)懕P

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

頁(yè)緩存

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

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

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

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

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

零拷貝

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

附

一個(gè)磁盤IO流程可以參考下圖： 

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

寫在最后

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