面試官:說說Kafka為什么速度那么快颖医?

作者:邴越
博客園文章地址:
cnblogs.com/binyue/p/10308754.html

Kafka的消息是保存或緩存在磁盤上的,一般認(rèn)為在磁盤上讀寫數(shù)據(jù)是會降低性能的传黄,因為尋址會比較消耗時間佳谦,但是實際上,Kafka的特性之一就是高吞吐率熄阻。

即使是普通的服務(wù)器斋竞,Kafka也可以輕松支持每秒百萬級的寫入請求,超過了大部分的消息中間件饺律,這種特性也使得Kafka在日志處理等海量數(shù)據(jù)場景廣泛應(yīng)用窃页。

針對Kafka的基準(zhǔn)測試可以參考:

Apache Kafka基準(zhǔn)測試:每秒寫入2百萬(在三臺廉價機器上)ifeve.com/benchmarking-apache-kafka-2-million-writes-second-three-cheap-machines/

下面從數(shù)據(jù)寫入和讀取兩方面分析,為什么Kafka速度這么快复濒。

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

Kafka會把收到的消息都寫入到硬盤中脖卖,它絕對不會丟失數(shù)據(jù)。為了優(yōu)化寫入速度Kafka采用了兩個技術(shù)巧颈, 順序?qū)懭?和 MMFile 畦木。

順序?qū)懭?/strong>

磁盤讀寫的快慢取決于你怎么使用它,也就是順序讀寫或者隨機讀寫砸泛。在順序讀寫的情況下十籍,某些優(yōu)化場景磁盤的讀寫速度可以和內(nèi)存持平

注:此處有疑問蛆封, 不推敲細(xì)節(jié),參考 http://searene.me/2017/07/09/Why-is-Kafka-so-fast/

因為硬盤是機械結(jié)構(gòu)勾栗,每次讀寫都會尋址->寫入惨篱,其中尋址是一個“機械動作”,它是最耗時的围俘。

所以硬盤最討厭隨機I/O砸讳,最喜歡順序I/O。為了提高讀寫硬盤的速度界牡,Kafka就是使用順序I/O簿寂。

而且Linux對于磁盤的讀寫優(yōu)化也比較多,包括read-ahead和write-behind宿亡,磁盤緩存等常遂。

如果在內(nèi)存做這些操作的時候,一個是JAVA對象的內(nèi)存開銷很大挽荠,另一個是隨著堆內(nèi)存數(shù)據(jù)的增多克胳,JAVA的GC時間會變得很長,使用磁盤操作有以下幾個好處:

  • 磁盤順序讀寫速度超過內(nèi)存隨機讀寫
  • JVM的GC效率低坤按,內(nèi)存占用大毯欣。使用磁盤可以避免這一問題
  • 系統(tǒng)冷啟動后,磁盤緩存依然可用
image

上圖就展示了Kafka是如何寫入數(shù)據(jù)的臭脓, 每一個Partition其實都是一個文件 酗钞,收到消息后Kafka會把數(shù)據(jù)插入到文件末尾(虛框部分)。

這種方法有一個缺陷—— 沒有辦法刪除數(shù)據(jù) 来累,所以Kafka是不會刪除數(shù)據(jù)的砚作,它會把所有的數(shù)據(jù)都保留下來,每個消費者(Consumer)對每個Topic都有一個offset用來表示 讀取到了第幾條數(shù)據(jù) 嘹锁。
image

兩個消費者葫录,Consumer1有兩個offset分別對應(yīng)Partition0、Partition1(假設(shè)每一個Topic一個Partition)领猾;Consumer2有一個offset對應(yīng)Partition2米同。

這個offset是由客戶端SDK負(fù)責(zé)保存的,Kafka的Broker完全無視這個東西的存在摔竿;一般情況下SDK會把它保存到zookeeper里面面粮。(所以需要給Consumer提供zookeeper的地址)。

如果不刪除硬盤肯定會被撐滿继低,所以Kakfa提供了兩種策略來刪除數(shù)據(jù)熬苍。一是基于時間,二是基于partition文件大小。具體配置可以參看它的配置文檔柴底。

Memory Mapped Files

即便是順序?qū)懭胗脖P婿脸,硬盤的訪問速度還是不可能追上內(nèi)存。所以Kafka的數(shù)據(jù)并 不是實時的寫入硬盤 柄驻,它充分利用了現(xiàn)代操作系統(tǒng) 分頁存儲 來利用內(nèi)存提高I/O效率狐树。

Memory Mapped Files(后面簡稱mmap)也被翻譯成 內(nèi)存映射文件 ,在64位操作系統(tǒng)中一般可以表示20G的數(shù)據(jù)文件凿歼,它的工作原理是直接利用操作系統(tǒng)的Page來實現(xiàn)文件到物理內(nèi)存的直接映射褪迟。

完成映射之后你對物理內(nèi)存的操作會被同步到硬盤上(操作系統(tǒng)在適當(dāng)?shù)臅r候)。

通過mmap答憔,進(jìn)程像讀寫硬盤一樣讀寫內(nèi)存(當(dāng)然是虛擬機內(nèi)存),也不必關(guān)心內(nèi)存的大小有虛擬內(nèi)存為我們兜底掀抹。

使用這種方式可以獲取很大的I/O提升虐拓, 省去了用戶空間到內(nèi)核空間 復(fù)制的開銷(調(diào)用文件的read會把數(shù)據(jù)先放到內(nèi)核空間的內(nèi)存中,然后再復(fù)制到用戶空間的內(nèi)存中傲武。)

也有一個很明顯的缺陷——不可靠蓉驹, 寫到mmap中的數(shù)據(jù)并沒有被真正的寫到硬盤,操作系統(tǒng)會在程序主動調(diào)用flush的時候才把數(shù)據(jù)真正的寫到硬盤揪利。

Kafka提供了一個參數(shù)——producer.type來控制是不是主動flush态兴,如果Kafka寫入到mmap之后就立即flush然后再返回Producer叫 同步 (sync);寫入mmap之后立即返回Producer不調(diào)用flush叫 異步 (async)疟位。

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

Kafka在讀取磁盤時做了哪些優(yōu)化瞻润?

基于sendfile實現(xiàn)Zero Copy

傳統(tǒng)模式下,當(dāng)需要對一個文件進(jìn)行傳輸?shù)臅r候甜刻,其具體流程細(xì)節(jié)如下:

  1. 調(diào)用read函數(shù)绍撞,文件數(shù)據(jù)被copy到內(nèi)核緩沖區(qū)

  2. read函數(shù)返回,文件數(shù)據(jù)從內(nèi)核緩沖區(qū)copy到用戶緩沖區(qū)

  3. write函數(shù)調(diào)用得院,將文件數(shù)據(jù)從用戶緩沖區(qū)copy到內(nèi)核與socket相關(guān)的緩沖區(qū)傻铣。

  4. 數(shù)據(jù)從socket緩沖區(qū)copy到相關(guān)協(xié)議引擎。

以上細(xì)節(jié)是傳統(tǒng)read/write方式進(jìn)行網(wǎng)絡(luò)文件傳輸?shù)姆绞较榻剩覀兛梢钥吹椒侵蓿谶@個過程當(dāng)中,文件數(shù)據(jù)實際上是經(jīng)過了四次copy操作:

硬盤—>內(nèi)核buf—>用戶buf—>socket相關(guān)緩沖區(qū)—>協(xié)議引擎

而sendfile系統(tǒng)調(diào)用則提供了一種減少以上多次copy蜕径,提升文件傳輸性能的方法两踏。

在內(nèi)核版本2.1中,引入了sendfile系統(tǒng)調(diào)用丧荐,以簡化網(wǎng)絡(luò)上和兩個本地文件之間的數(shù)據(jù)傳輸缆瓣。sendfile的引入不僅減少了數(shù)據(jù)復(fù)制,還減少了上下文切換虹统。

sendfile(socket, file, len);

運行流程如下:

  1. sendfile系統(tǒng)調(diào)用弓坞,文件數(shù)據(jù)被copy至內(nèi)核緩沖區(qū)

  2. 再從內(nèi)核緩沖區(qū)copy至內(nèi)核中socket相關(guān)的緩沖區(qū)

  3. 最后在socket相關(guān)的緩沖區(qū)copy到協(xié)議引擎

相較傳統(tǒng)read/write方式隧甚,2.1版本內(nèi)核引進(jìn)的sendfile已經(jīng)減少了內(nèi)核緩沖區(qū)到user緩沖區(qū),再由user緩沖區(qū)到socket相關(guān)緩沖區(qū)的文件copy

而在內(nèi)核版本2.4之后渡冻,文件描述符結(jié)果被改變戚扳,sendfile實現(xiàn)了更簡單的方式,再次減少了一次copy操作族吻。

在apache帽借,nginx,lighttpd等web服務(wù)器當(dāng)中超歌,都有一項sendfile相關(guān)的配置砍艾,使用sendfile可以大幅提升文件傳輸性能。

Kafka把所有的消息都存放在一個一個的文件中巍举,當(dāng)消費者需要數(shù)據(jù)的時候Kafka直接把文件發(fā)送給消費者脆荷,配合mmap作為文件讀寫方式,直接把它傳給sendfile懊悯。

批量壓縮

在很多情況下蜓谋,系統(tǒng)的瓶頸不是CPU或磁盤,而是網(wǎng)絡(luò)IO炭分,對于需要在廣域網(wǎng)上的數(shù)據(jù)中心之間發(fā)送消息的數(shù)據(jù)流水線尤其如此桃焕。

進(jìn)行數(shù)據(jù)壓縮會消耗少量的CPU資源,不過對于kafka而言,網(wǎng)絡(luò)IO更應(yīng)該需要考慮。

  • 如果每個消息都壓縮捧毛,但是壓縮率相對很低观堂,所以Kafka使用了批量壓縮,即將多個消息一起壓縮而不是單個消息壓縮

  • Kafka允許使用遞歸的消息集合岖妄,批量的消息可以通過壓縮的形式傳輸并且在日志中也可以保持壓縮格式型将,直到被消費者解壓縮

  • Kafka支持多種壓縮協(xié)議,包括Gzip和Snappy壓縮協(xié)議

總結(jié)

Kafka速度的秘訣在于荐虐,它把所有的消息都變成一個批量的文件七兜,并且進(jìn)行合理的批量壓縮,減少網(wǎng)絡(luò)IO損耗福扬,通過mmap提高I/O速度腕铸,寫入數(shù)據(jù)的時候由于單個Partion是末尾添加所以速度最優(yōu);讀取數(shù)據(jù)的時候配合sendfile直接暴力輸出铛碑。

?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
  • 序言:七十年代末狠裹,一起剝皮案震驚了整個濱河市,隨后出現(xiàn)的幾起案子汽烦,更是在濱河造成了極大的恐慌涛菠,老刑警劉巖,帶你破解...
    沈念sama閱讀 223,002評論 6 519
  • 序言:濱河連續(xù)發(fā)生了三起死亡事件,死亡現(xiàn)場離奇詭異俗冻,居然都是意外死亡礁叔,警方通過查閱死者的電腦和手機,發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 95,357評論 3 400
  • 文/潘曉璐 我一進(jìn)店門迄薄,熙熙樓的掌柜王于貴愁眉苦臉地迎上來琅关,“玉大人,你說我怎么就攤上這事讥蔽』烈祝” “怎么了?”我有些...
    開封第一講書人閱讀 169,787評論 0 365
  • 文/不壞的土叔 我叫張陵冶伞,是天一觀的道長新症。 經(jīng)常有香客問我,道長碰缔,這世上最難降的妖魔是什么账劲? 我笑而不...
    開封第一講書人閱讀 60,237評論 1 300
  • 正文 為了忘掉前任,我火速辦了婚禮金抡,結(jié)果婚禮上,老公的妹妹穿的比我還像新娘腌且。我一直安慰自己梗肝,他們只是感情好,可當(dāng)我...
    茶點故事閱讀 69,237評論 6 398
  • 文/花漫 我一把揭開白布铺董。 她就那樣靜靜地躺著巫击,像睡著了一般。 火紅的嫁衣襯著肌膚如雪精续。 梳的紋絲不亂的頭發(fā)上坝锰,一...
    開封第一講書人閱讀 52,821評論 1 314
  • 那天,我揣著相機與錄音重付,去河邊找鬼顷级。 笑死,一個胖子當(dāng)著我的面吹牛确垫,可吹牛的內(nèi)容都是我干的弓颈。 我是一名探鬼主播,決...
    沈念sama閱讀 41,236評論 3 424
  • 文/蒼蘭香墨 我猛地睜開眼删掀,長吁一口氣:“原來是場噩夢啊……” “哼翔冀!你這毒婦竟也來了?” 一聲冷哼從身側(cè)響起披泪,我...
    開封第一講書人閱讀 40,196評論 0 277
  • 序言:老撾萬榮一對情侶失蹤纤子,失蹤者是張志新(化名)和其女友劉穎,沒想到半個月后,有當(dāng)?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體控硼,經(jīng)...
    沈念sama閱讀 46,716評論 1 320
  • 正文 獨居荒郊野嶺守林人離奇死亡泽论,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內(nèi)容為張勛視角 年9月15日...
    茶點故事閱讀 38,794評論 3 343
  • 正文 我和宋清朗相戀三年,在試婚紗的時候發(fā)現(xiàn)自己被綠了象颖。 大學(xué)時的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片佩厚。...
    茶點故事閱讀 40,928評論 1 353
  • 序言:一個原本活蹦亂跳的男人離奇死亡,死狀恐怖说订,靈堂內(nèi)的尸體忽然破棺而出抄瓦,到底是詐尸還是另有隱情,我是刑警寧澤陶冷,帶...
    沈念sama閱讀 36,583評論 5 351
  • 正文 年R本政府宣布钙姊,位于F島的核電站,受9級特大地震影響埂伦,放射性物質(zhì)發(fā)生泄漏煞额。R本人自食惡果不足惜,卻給世界環(huán)境...
    茶點故事閱讀 42,264評論 3 336
  • 文/蒙蒙 一沾谜、第九天 我趴在偏房一處隱蔽的房頂上張望膊毁。 院中可真熱鬧,春花似錦基跑、人聲如沸婚温。這莊子的主人今日做“春日...
    開封第一講書人閱讀 32,755評論 0 25
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽栅螟。三九已至,卻和暖如春篱竭,著一層夾襖步出監(jiān)牢的瞬間力图,已是汗流浹背。 一陣腳步聲響...
    開封第一講書人閱讀 33,869評論 1 274
  • 我被黑心中介騙來泰國打工掺逼, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留吃媒,地道東北人。 一個月前我還...
    沈念sama閱讀 49,378評論 3 379
  • 正文 我出身青樓坪圾,卻偏偏與公主長得像晓折,于是被迫代替她去往敵國和親。 傳聞我的和親對象是個殘疾皇子兽泄,可洞房花燭夜當(dāng)晚...
    茶點故事閱讀 45,937評論 2 361