資深程序員多年總結(jié):解密Kafka吞吐量高的原因

2021-02-04    分類: 網(wǎng)站建設(shè)

眾所周知kafka的吞吐量比一般的消息隊(duì)列要高,號(hào)稱the fastest,那他是如何做到的,讓我們從以下幾個(gè)方面分析一下原因。

生產(chǎn)者(寫入數(shù)據(jù))

生產(chǎn)者(producer)是負(fù)責(zé)向Kafka提交數(shù)據(jù)的,我們先分析這一部分。
Kafka會(huì)把收到的消息都寫入到硬盤中,它絕對(duì)不會(huì)丟失數(shù)據(jù)。為了優(yōu)化寫入速度Kafak采用了兩個(gè)技術(shù),順序?qū)懭牒蚆MFile。

順序?qū)懭?

因?yàn)橛脖P是機(jī)械結(jié)構(gòu),每次讀寫都會(huì)尋址->寫入,其中尋址是一個(gè)“機(jī)械動(dòng)作”,它是最耗時(shí)的。所以硬盤最“討厭”隨機(jī)I/O,最喜歡順序I/O為了提高讀寫硬盤的速度,Kafka就是使用順序I/O

通過mmap,進(jìn)程像讀寫硬盤一樣讀寫內(nèi)存(當(dāng)然是虛擬機(jī)內(nèi)存),也不必關(guān)心內(nèi)存的大小有虛擬內(nèi)存為我們兜底。
使用這種方式可以獲取很大的I/O提升,省去了用戶

先復(fù)制到內(nèi)核

Zero Copy中直接從內(nèi)核空間(DMA的)到內(nèi)核空間(Socket的),然后發(fā)送網(wǎng)卡。
這個(gè)技術(shù)非常普遍,The C10K problem 里面也有很詳細(xì)的介紹,Nginx也是用的這種技術(shù),稍微搜一下就能找到很多資料。

Java的NIO提供了FileChannle,它的transferTo、transferFrom方法就是Zero Copy。

Kafka是如何耍賴的?

想到了嗎?Kafka把所有的消息都存放在一個(gè)一個(gè)的文件中,當(dāng)消費(fèi)者需要數(shù)據(jù)的時(shí)候Kafka直接把“文件”發(fā)送給消費(fèi)者。這就是秘訣所在,比如:10W的消息組合在一起是10MB的數(shù)據(jù)量,然后Kafka用類似于發(fā)文件的方式直接扔出去了,如果消費(fèi)者和生產(chǎn)者之間的網(wǎng)絡(luò)非常好(只要網(wǎng)絡(luò)稍微正常一點(diǎn)10MB根本不是事。。。家里上網(wǎng)都是100Mbps的帶寬了),10MB可能只需要1s。所以答案是——10W的TPS,Kafka每秒鐘處理了10W條消息。
可能你說:不可能把整個(gè)文件發(fā)出去吧?里面還有一些不需要的消息呢?是的,Kafka作為一個(gè)“高級(jí)作弊分子”自然要把作弊做的有逼格。Zero Copy對(duì)應(yīng)的是sendfile這個(gè)函數(shù)(以Linux為例),這個(gè)函數(shù)接受

out_fd作為輸出(一般及時(shí)socket的句柄)

in_fd作為輸入文件句柄

off_t表示in_fd的偏移(從哪里開始讀?。?/p>

size_t表示讀取多少個(gè)

沒錯(cuò),Kafka是用mmap作為文件讀寫方式的,它就是一個(gè)文件句柄,所以直接把它傳給sendfile;偏移也好解決,用戶會(huì)自己保持這個(gè)offset,每次請(qǐng)求都會(huì)發(fā)送這個(gè)offset。(還記得嗎?放在zookeeper中的);數(shù)據(jù)量更容易解決了,如果消費(fèi)者想要更快,就全部扔給消費(fèi)者。如果這樣做一般情況下消費(fèi)者肯定直接就被壓死了;所以Kafka提供了的兩種方式——Push,我全部扔給你了,你死了不管我的事情;Pull,好吧你告訴我你需要多少個(gè),我給你多少個(gè)。

總結(jié)

Kafka速度的秘訣在于,它把所有的消息都變成一個(gè)的文件。通過mmap提高I/O速度,寫入數(shù)據(jù)的時(shí)候它是末尾添加所以速度最優(yōu);讀取數(shù)據(jù)的時(shí)候配合sendfile直接暴力輸出。阿里的RocketMQ也是這種模式,只不過是用Java寫的。

單純的去測(cè)試MQ的速度沒有任何意義,Kafka這種“暴力”、“流氓”、“無恥”的做法已經(jīng)脫了MQ的底褲,更像是一個(gè)暴力的“數(shù)據(jù)傳送器”。所以對(duì)于一個(gè)MQ的評(píng)價(jià)只以速度論英雄,世界上沒人能干的過Kafka,我們?cè)O(shè)計(jì)的時(shí)候不能聽信網(wǎng)上的流言蜚語(yǔ)——“Kafka最快,大家都在用,所以我們的MQ用Kafka沒錯(cuò)”。在這種思想的作用下,你可能根本不會(huì)關(guān)心“失敗者”;而實(shí)際上可能這些“失敗者”是更適合你業(yè)務(wù)的MQ。

文章名稱:資深程序員多年總結(jié):解密Kafka吞吐量高的原因
文章來源:http://www.bm7419.com/news/99160.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián),為您提供微信公眾號(hào)、外貿(mào)建站、建站公司、做網(wǎng)站、Google用戶體驗(yàn)

廣告

聲明:本網(wǎng)站發(fā)布的內(nèi)容(圖片、視頻和文字)以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主,如果涉及侵權(quán)請(qǐng)盡快告知,我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng),如需處理請(qǐng)聯(lián)系客服。電話:028-86922220;郵箱:631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載,或轉(zhuǎn)載時(shí)需注明來源: 創(chuàng)新互聯(lián)

微信小程序開發(fā)