前言
有人說：他曾在一臺配置較好的機子上對 Kafka 進行性能壓測，壓測結(jié)果是 Kafka 單個節(jié)點的極限處理能力接近每秒 2000萬 條消息，吞吐量達到每秒 600MB。
那 Kafka 為什么這么快？如何做到這個高的性能？
本篇文章主要從這 3 個角度來分析：
- 生產(chǎn)端
- 服務(wù)端 Broker
- 消費端
先來看下生產(chǎn)端發(fā)送消息，Kafka 做了哪些優(yōu)化？
（1）生產(chǎn)端 Producer
Producer 生產(chǎn)者發(fā)送消息的流程
- 首先指定消息發(fā)送到哪個 Topic。
- 選擇一個 Topic 的分區(qū) partitiion，默認是輪詢來負載均衡。也可以指定一個分區(qū) key，根據(jù) key 的 hash 值來分發(fā)到指定的分區(qū)。也可以自定義 partition 來實現(xiàn)分區(qū)策略。
- 找到這個分區(qū)的 leader partition。
- 與所在機器的 Broker 的 socket 建立通信。
- 發(fā)送 Kafka 自定義協(xié)議格式的請求（包含攜帶的消息、批量消息）。
將思緒集中在消息發(fā)送時候，可發(fā)現(xiàn)這兩個華點：批量消息和自定義協(xié)議格式。
- 批量發(fā)送：減少了與服務(wù)端 Broker 處理請求的次數(shù)，從而提升總體的處理能力。調(diào)用 send() 方法時，不會立刻把消息發(fā)送出去，而是緩存起來，選擇恰當(dāng)時機把緩存里的消息劃分成一批數(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ū)懭?/li>
- 零拷貝 sendfile：加速消費流程
下面展開講講。
1）PageCache 加速消息讀寫
使用 PageCache 主要能帶來如下好處：
-
寫入文件的時候：操作系統(tǒng)會先把數(shù)據(jù)寫入到內(nèi)存中的 PageCache，然后再一批一批地寫到磁盤上，從而減少磁盤 IO 開銷。
-
讀取文件的時候：也是從 PageCache 中來讀取數(shù)據(jù)。
如果消息剛剛寫入到服務(wù)端就會被消費，按照 LRU 的“優(yōu)先清除最近最少使用的頁”這種策略，讀取的時候，對于這種剛剛寫入的
PageCache，命中的幾率會非常高。
2）Kafka 的文件布局 以及 磁盤文件順序?qū)懭?/h3>
文件布局如下圖所示：
主要特征是：文件的組織方式是“topic + 分區(qū)”，每一個 topic 可以創(chuàng)建多個分區(qū)，每一個分區(qū)包含單獨的文件夾。
Kafka 在分區(qū)級別實現(xiàn)文件順序?qū)?/strong>：即多個文件同時寫入，更能發(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ù)時：
流程如下：
- 消費端 Consumer：向 Kafka Broker 請求拉取消息
- Kafka Broker 從 OS Cache 讀取消息到 應(yīng)用程序的內(nèi)存空間：
a. 若 OS Cache 中有消息，則直接讀取
b. 若 OS Cache 中無消息，則從磁盤里讀取 - 再通過網(wǎng)卡，socket 將數(shù)據(jù)發(fā)送給 消費端Consumer
當(dāng)使用零拷貝技術(shù)讀取數(shù)據(jù)：
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)建消費組(唯一標識 group.id)，在同一個消費組的消費者共同消費數(shù)據(jù)。
舉個栗子：
- 有兩個 Kafka Broker，即有 2個機子
- 有一個主題：TOPICA，有 3 個分區(qū)(0, 1, 2)
文章來源：http://www.zghlxwxcb.cn/news/detail-814642.html
如上圖，舉例 4 中情況：文章來源地址http://www.zghlxwxcb.cn/news/detail-814642.html
- 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)
到了這里，關(guān)于面試題：Kafka 為什么那么快？的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！
