有人說：他曾在一臺配置較好的機(jī)子上對 Kafka 進(jìn)行性能壓測，壓測結(jié)果是 Kafka 單個節(jié)點的極限處理能力接近每秒 2000萬 條消息，吞吐量達(dá)到每秒 600MB。

那 Kafka 為什么這么快？如何做到這個高的性能？

本篇文章主要從這 3 個角度來分析：

生產(chǎn)端

服務(wù)端 Broker

消費端

先來看下生產(chǎn)端發(fā)送消息，Kafka 做了哪些優(yōu)化？

（1）生產(chǎn)端 Producer

partition寫入與消費

先來回顧下 Producer 生產(chǎn)者發(fā)送消息的流程：

首先指定消息發(fā)送到哪個 Topic。

選擇一個 Topic 的分區(qū) partitiion，默認(rèn)是輪詢來負(fù)載均衡。

也可以指定一個分區(qū) key，根據(jù) key 的 hash 值來分發(fā)到指定的分區(qū)。

也可以自定義 partition 來實現(xiàn)分區(qū)策略。

找到這個分區(qū)的 leader partition。

與所在機(jī)器的 Broker 的 socket 建立通信。

發(fā)送 Kafka 自定義協(xié)議格式的請求（包含攜帶的消息、批量消息）。

將思緒集中在消息發(fā)送時候，可發(fā)現(xiàn)這兩個華點：批量消息和自定義協(xié)議格式。

批量發(fā)送：減少了與服務(wù)端 Broker 處理請求的次數(shù)，從而提升總體的處理能力。

調(diào)用 send() 方法時，不會立刻把消息發(fā)送出去，而是緩存起來，選擇恰當(dāng)時機(jī)把緩存里的消息劃分成一批數(shù)據(jù)，按批次發(fā)送給服務(wù)端 Broker。

自定義協(xié)議格式：序列化方式和壓縮格式都能減少數(shù)據(jù)體積，從而節(jié)省網(wǎng)絡(luò)資源消耗。

各種壓縮算法對比：

吞吐量方面：LZ4 > Snappy > zstd 和 GZIP

壓縮比方面：zstd > LZ4 > GZIP > Snappy

（2）服務(wù)端 Broker

Broker 的高性能主要從這 3 個方面體現(xiàn)：

PageCache 緩存

Kafka 的文件布局 以及 磁盤文件順序?qū)懭?/p>

零拷貝 sendfile：加速消費流程

下面展開講講。

1）PageCache 加速消息讀寫

使用 PageCache 主要能帶來如下好處：

寫入文件的時候：操作系統(tǒng)會先把數(shù)據(jù)寫入到內(nèi)存中的 PageCache，然后再一批一批地寫到磁盤上，從而減少磁盤 IO 開銷。

數(shù)據(jù)寫入

讀取文件的時候：也是從 PageCache 中來讀取數(shù)據(jù)。

如果消息剛剛寫入到服務(wù)端就會被消費，按照 LRU 的“優(yōu)先清除最近最少使用的頁”這種策略，讀取的時候，對于這種剛剛寫入的 PageCache，命中的幾率會非常高。

2）Kafka 的文件布局 以及 磁盤文件順序?qū)懭?/p>

文件布局如下圖所示：

主要特征是：文件的組織方式是“topic + 分區(qū)”，每一個 topic 可以創(chuàng)建多個分區(qū)，每一個分區(qū)包含單獨的文件夾。

Kafka 在分區(qū)級別實現(xiàn)文件順序?qū)懀杭炊鄠€文件同時寫入，更能發(fā)揮磁盤 IO 的性能。

相對比 RocketMQ： RocketMQ 在消息寫入時追求極致的順序?qū)懀械南⒉环种黝}一律順序?qū)懭?commitlog 文件， topic 和 分區(qū)數(shù)量的增加不會影響寫入順序。

弊端： Kafka 在消息寫入時的 IO 性能，會隨著 topic 、分區(qū)數(shù)量的增長先上升，后下降。

所以使用 Kafka 時，要警惕 Topic 和 分區(qū)數(shù)量。

3）零拷貝 sendfile：加速消費流程

當(dāng)不使用零拷貝技術(shù)讀取數(shù)據(jù)時：

數(shù)據(jù)讀取

流程如下：

消費端 Consumer：向 Kafka Broker 請求拉取消息

Kafka Broker 從 OS Cache 讀取消息到 應(yīng)用程序的內(nèi)存空間：

若 OS Cache 中有消息，則直接讀取

若 OS Cache 中無消息，則從磁盤里讀取

再通過網(wǎng)卡，socket 將數(shù)據(jù)發(fā)送給 消費端Consumer

當(dāng)使用零拷貝技術(shù)讀取數(shù)據(jù)：

數(shù)據(jù)讀取2

Kafka 使用零拷貝技術(shù)可以把這個復(fù)制次數(shù)減少一次，直接從 PageCache 中把數(shù)據(jù)復(fù)制到 Socket 緩沖區(qū)中。

這樣不用將數(shù)據(jù)復(fù)制到用戶內(nèi)存空間。

DMA 控制器直接完成數(shù)據(jù)復(fù)制，不需要 CPU 參與，速度更快。

（3）消費端 Consumer

消費者只從 Leader分區(qū)批量拉取消息。

為了提高消費速度，多個消費者并行消費比不可少。Kafka 允許創(chuàng)建消費組(唯一標(biāo)識 group.id)，在同一個消費組的消費者共同消費數(shù)據(jù)。

舉個栗子：

有兩個 Kafka Broker，即有 2個機(jī)子

有一個主題：TOPICA，有 3 個分區(qū)(0, 1, 2)

如上圖，舉例 4 中情況：

group.id = 1，有一個消費者：這個消費者要處理所有數(shù)據(jù)，即 3 個分區(qū)的數(shù)據(jù)。

group.id = 2，有兩個消費者：consumer 1消費者需處理 2個分區(qū)的數(shù)據(jù)，consumer2 消費者需處理 1個分區(qū)的數(shù)據(jù)

group.id = 3，有三個消費者：消費者數(shù)量與分區(qū)數(shù)量相等，剛好每個消費者處理一個分區(qū)

group.id = 4，有四個消費者：消費者數(shù)量 > 分區(qū)數(shù)量，第四個消費者則會處于空閑狀態(tài)