有人說(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
先來(lái)回顧下?Producer 生產(chǎn)者發(fā)送消息的流程：
-
首先指定消息發(fā)送到哪個(gè)?
Topic。 -
選擇一個(gè)?
Topic?的分區(qū)?partitiion，默認(rèn)是輪詢(xú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?的文件布局 以及 磁盤(pán)文件順序?qū)懭?/p> -
零拷貝?
sendfile：加速消費(fèi)流程
下面展開(kāi)講講。
1）PageCache 加速消息讀寫(xiě)
使用?PageCache?主要能帶來(lái)如下好處：
-
寫(xiě)入文件的時(shí)候：操作系統(tǒng)會(huì)先把數(shù)據(jù)寫(xiě)入到內(nèi)存中的?
PageCache，然后再一批一批地寫(xiě)到磁盤(pán)上，從而減少磁盤(pán)?IO?開(kāi)銷(xiāo)。
-
讀取文件的時(shí)候：也是從?
PageCache?中來(lái)讀取數(shù)據(jù)。
如果消息剛剛寫(xiě)入到服務(wù)端就會(huì)被消費(fèi)，按照?
LRU?的“優(yōu)先清除最近最少使用的頁(yè)”這種策略，讀取的時(shí)候，對(duì)于這種剛剛寫(xiě)入的?PageCache，命中的幾率會(huì)非常高。
2）Kafka 的文件布局 以及 磁盤(pán)文件順序?qū)懭?/p>
文件布局如下圖所示：
主要特征是：文件的組織方式是“topic?+ 分區(qū)”，每一個(gè)?topic?可以創(chuàng)建多個(gè)分區(qū)，每一個(gè)分區(qū)包含單獨(dú)的文件夾。
Kafka?在分區(qū)級(jí)別實(shí)現(xiàn)文件順序?qū)?/strong>：即多個(gè)文件同時(shí)寫(xiě)入，更能發(fā)揮磁盤(pán)?IO?的性能。
-
相對(duì)比?
RocketMQ：?RocketMQ?在消息寫(xiě)入時(shí)追求極致的順序?qū)?，所有的消息不分主題一律順序?qū)懭?commitlog?文件，?topic?和 分區(qū)數(shù)量的增加不會(huì)影響寫(xiě)入順序。 -
弊端：?
Kafka?在消息寫(xiě)入時(shí)的?IO?性能，會(huì)隨著?topic?、分區(qū)數(shù)量的增長(zhǎng)先上升，后下降。所以使用?
Kafka?時(shí)，要警惕?Topic?和 分區(qū)數(shù)量。
3）零拷貝 sendfile：加速消費(fèi)流程
當(dāng)不使用零拷貝技術(shù)讀取數(shù)據(jù)時(shí)：
流程如下：
-
消費(fèi)端?
Consumer：向?Kafka Broker?請(qǐng)求拉取消息 -
Kafka Broker?從?OS Cache?讀取消息到 應(yīng)用程序的內(nèi)存空間：-
若?
OS Cache?中有消息，則直接讀取 -
若?
OS Cache?中無(wú)消息，則從磁盤(pán)里讀取
-
-
再通過(guò)網(wǎng)卡，
socket?將數(shù)據(jù)發(fā)送給 消費(fèi)端Consumer
當(dāng)使用零拷貝技術(shù)讀取數(shù)據(jù)：
Kafka?使用零拷貝技術(shù)可以把這個(gè)復(fù)制次數(shù)減少一次，直接從?PageCache?中把數(shù)據(jù)復(fù)制到?Socket?緩沖區(qū)中。
-
這樣不用將數(shù)據(jù)復(fù)制到用戶(hù)內(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ū)文章來(lái)源：http://www.zghlxwxcb.cn/news/detail-533148.html -
group.id = 4，有四個(gè)消費(fèi)者：消費(fèi)者數(shù)量 > 分區(qū)數(shù)量，第四個(gè)消費(fèi)者則會(huì)處于空閑狀態(tài)文章來(lái)源地址http://www.zghlxwxcb.cn/news/detail-533148.html
到了這里，關(guān)于Kafka 為什么那么快？的文章就介紹完了。如果您還想了解更多內(nèi)容，請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！
