Kafka 為什么那么快？

上一篇：Alibaba開源內(nèi)網(wǎng)高并發(fā)編程手冊.pdf

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

• 生產(chǎn)端
• 服務(wù)端 Broker
• 消費(fèi)端

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

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

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

1. 首先指定消息發(fā)送到哪個(gè) Topic。
2. 選擇一個(gè) Topic 的分區(qū) partitiion，默認(rèn)是輪詢來負(fù)載均衡。

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

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

3. 找到這個(gè)分區(qū)的 leader partition。
4. 與所在機(jī)器的 Broker 的 socket 建立通信。
5. 發(fā)送 Kafka 自定義協(xié)議格式的請求（包含攜帶的消息、批量消息）。

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

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

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

• 吞吐量方面：LZ4 > Snappy > zstd 和 GZIP
• 壓縮比方面：zstd > LZ4 > GZIP > Snappy

（2）服務(wù)端 Broker

1. PageCache 緩存
2. Kafka 的文件布局 以及 磁盤文件順序?qū)懭?/section>
3. 零拷貝 sendfile：加速消費(fèi)流程

下面展開講講。

1）PageCache 加速消息讀寫

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

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

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

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

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

• 相對比 RocketMQ： RocketMQ 在消息寫入時(shí)追求極致的順序?qū)懀械南⒉环种黝}一律順序?qū)懭?nbsp;commitlog 文件， topic 和 分區(qū)數(shù)量的增加不會影響寫入順序。
• 弊端： Kafka 在消息寫入時(shí)的 IO 性能，會隨著 topic 、分區(qū)數(shù)量的增長先上升，后下降。

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

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

1. 消費(fèi)端 Consumer：向 Kafka Broker 請求拉取消息
2. Kafka Broker 從 OS Cache 讀取消息到 應(yīng)用程序的內(nèi)存空間：
1. 若 OS Cache 中有消息，則直接讀取
2. 若 OS Cache 中無消息，則從磁盤里讀取
3. 再通過網(wǎng)卡，socket 將數(shù)據(jù)發(fā)送給 消費(fèi)端Consumer

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

• 這樣不用將數(shù)據(jù)復(fù)制到用戶內(nèi)存空間。
• DMA 控制器直接完成數(shù)據(jù)復(fù)制，不需要 CPU 參與，速度更快。

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

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

• 有兩個(gè) Kafka Broker，即有 2個(gè)機(jī)子
• 有一個(gè)主題：TOPICA，有 3 個(gè)分區(qū)(0, 1, 2)

1. group.id = 1，有一個(gè)消費(fèi)者：這個(gè)消費(fèi)者要處理所有數(shù)據(jù)，即 3 個(gè)分區(qū)的數(shù)據(jù)。
2. group.id = 2，有兩個(gè)消費(fèi)者：consumer 1消費(fèi)者需處理 2個(gè)分區(qū)的數(shù)據(jù)，consumer2 消費(fèi)者需處理 1個(gè)分區(qū)的數(shù)據(jù)
3. group.id = 3，有三個(gè)消費(fèi)者：消費(fèi)者數(shù)量與分區(qū)數(shù)量相等，剛好每個(gè)消費(fèi)者處理一個(gè)分區(qū)
4. group.id = 4，有四個(gè)消費(fèi)者：消費(fèi)者數(shù)量 > 分區(qū)數(shù)量，第四個(gè)消費(fèi)者則會處于空閑狀態(tài)