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

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

本篇文章主要從這 3 個(gè)角度來(lái)分析：

生產(chǎn)端

服務(wù)端 Broker

消費(fèi)端

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

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

partition寫入與消費(fèi)

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

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

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

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

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

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

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

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

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

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

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

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

各種壓縮算法對(duì)比：

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

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

（2）服務(wù)端 Broker

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

PageCache 緩存

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

零拷貝 sendfile：加速消費(fèi)流程

下面展開講講。

1）PageCache 加速消息讀寫

使用 PageCache 主要能帶來(lái)如下好處：

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

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

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

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

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

文件布局如下圖所示：

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

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

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

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

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

3）零拷貝 sendfile：加速消費(fèi)流程

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

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

流程如下：

消費(fèi)端 Consumer：向 Kafka Broker 請(qǐng)求拉取消息

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

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

若 OS Cache 中無(wú)消息，則從磁盤里讀取

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

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

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

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

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

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

（3）消費(fèi)端 Consumer

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

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

舉個(gè)栗子：

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

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

如上圖，舉例 4 中情況：

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

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

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

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