Kafka如何實(shí)現(xiàn)每秒上百萬的超高并發(fā)寫入?
這篇文章來聊一下 Kafka 的一些架構(gòu)設(shè)計(jì)原理,這也是互聯(lián)網(wǎng)公司面試時(shí)非常高頻的技術(shù)考點(diǎn)。
Kafka 是高吞吐低延遲的高并發(fā)、高性能的消息中間件,在大數(shù)據(jù)領(lǐng)域有極為廣泛的運(yùn)用。配置良好的 Kafka 集群甚至可以做到每秒幾十萬、上百萬的超高并發(fā)寫入。
那么 Kafka 到底是如何做到這么高的吞吐量和性能的呢?這篇文章我們來詳細(xì)說一下。
頁緩存技術(shù) + 磁盤順序?qū)?/span>
首先 Kafka 每次接收到數(shù)據(jù)都會往磁盤上去寫,如下圖所示:
那么在這里我們不禁有一個(gè)疑問了,如果把數(shù)據(jù)基于磁盤來存儲,頻繁的往磁盤文件里寫數(shù)據(jù),這個(gè)性能會不會很差?大家肯定都覺得磁盤寫性能是極差的。
沒錯(cuò),要是真的跟上面那個(gè)圖那么簡單的話,那確實(shí)這個(gè)性能是比較差的。
但是實(shí)際上 Kafka 在這里有極為優(yōu)秀和出色的設(shè)計(jì),就是為了保證數(shù)據(jù)寫入性能,首先 Kafka 是基于操作系統(tǒng)的頁緩存來實(shí)現(xiàn)文件寫入的。
操作系統(tǒng)本身有一層緩存,叫做 Page Cache,是在內(nèi)存里的緩存,我們也可以稱之為 OS Cache,意思就是操作系統(tǒng)自己管理的緩存。
你在寫入磁盤文件的時(shí)候,可以直接寫入這個(gè) OS Cache 里,也就是僅僅寫入內(nèi)存中,接下來由操作系統(tǒng)自己決定什么時(shí)候把 OS Cache 里的數(shù)據(jù)真的刷入磁盤文件中。
僅僅這一個(gè)步驟,就可以將磁盤文件寫性能提升很多了,因?yàn)槠鋵?shí)這里相當(dāng)于是在寫內(nèi)存,不是在寫磁盤,大家看下圖:
接著另外一個(gè)就是 kafka 寫數(shù)據(jù)的時(shí)候,非常關(guān)鍵的一點(diǎn),它是以磁盤順序?qū)懙姆绞絹韺懙摹?/p>
也就是說,僅僅將數(shù)據(jù)追加到文件的末尾,不是在文件的隨機(jī)位置來修改數(shù)據(jù)。
普通的機(jī)械磁盤如果你要是隨機(jī)寫的話,確實(shí)性能極差,也就是隨便找到文件的某個(gè)位置來寫數(shù)據(jù)。
但是如果你是追加文件末尾按照順序的方式來寫數(shù)據(jù)的話,那么這種磁盤順序?qū)懙男阅芑旧峡梢愿鷮憙?nèi)存的性能本身也是差不多的。
所以大家就知道了,上面那個(gè)圖里,Kafka 在寫數(shù)據(jù)的時(shí)候,一方面基于 OS 層面的 Page Cache 來寫數(shù)據(jù),所以性能很高,本質(zhì)就是在寫內(nèi)存罷了。
另外一個(gè),它是采用磁盤順序?qū)懙姆绞剑约词箶?shù)據(jù)刷入磁盤的時(shí)候,性能也是極高的,也跟寫內(nèi)存是差不多的。
基于上面兩點(diǎn),Kafka 就實(shí)現(xiàn)了寫入數(shù)據(jù)的超高性能。那么大家想想,假如說 Kafka 寫入一條數(shù)據(jù)要耗費(fèi) 1 毫秒的時(shí)間,那么是不是每秒就是可以寫入 1000 條數(shù)據(jù)?
但是假如 Kafka 的性能極高,寫入一條數(shù)據(jù)僅僅耗費(fèi) 0.01 毫秒呢?那么每秒是不是就可以寫入 10 萬條數(shù)據(jù)?
所以要保證每秒寫入幾萬甚至幾十萬條數(shù)據(jù)的核心點(diǎn),就是盡***可能提升每條數(shù)據(jù)寫入的性能,這樣就可以在單位時(shí)間內(nèi)寫入更多的數(shù)據(jù)量,提升吞吐量。
零拷貝技術(shù)
說完了寫入這塊,再來談?wù)勏M(fèi)這塊。
大家應(yīng)該都知道,從 Kafka 里我們經(jīng)常要消費(fèi)數(shù)據(jù),那么消費(fèi)的時(shí)候?qū)嶋H上就是要從 Kafka 的磁盤文件里讀取某條數(shù)據(jù)然后發(fā)送給下游的消費(fèi)者,如下圖所示:
那么這里如果頻繁的從磁盤讀數(shù)據(jù)然后發(fā)給消費(fèi)者,性能瓶頸在哪里呢?
假設(shè)要是 Kafka 什么優(yōu)化都不做,就是很簡單的從磁盤讀數(shù)據(jù)發(fā)送給下游的消費(fèi)者,那么大概過程如下所示:
- 先看看要讀的數(shù)據(jù)在不在 OS Cache 里,如果不在的話就從磁盤文件里讀取數(shù)據(jù)后放入 OS Cache。
- 接著從操作系統(tǒng)的 OS Cache 里拷貝數(shù)據(jù)到應(yīng)用程序進(jìn)程的緩存里,再從應(yīng)用程序進(jìn)程的緩存里拷貝數(shù)據(jù)到操作系統(tǒng)層面的 Socket 緩存里。
- ***從 Socket 緩存里提取數(shù)據(jù)后發(fā)送到網(wǎng)卡,***發(fā)送出去給下游消費(fèi)。
整個(gè)過程,如下圖所示:
大家看上圖,很明顯可以看到有兩次沒必要的拷貝吧!一次是從操作系統(tǒng)的 Cache 里拷貝到應(yīng)用進(jìn)程的緩存里,接著又從應(yīng)用程序緩存里拷貝回操作系統(tǒng)的 Socket 緩存里。
而且為了進(jìn)行這兩次拷貝,中間還發(fā)生了好幾次上下文切換,一會兒是應(yīng)用程序在執(zhí)行,一會兒上下文切換到操作系統(tǒng)來執(zhí)行。
所以這種方式來讀取數(shù)據(jù)是比較消耗性能的。Kafka 為了解決這個(gè)問題,在讀數(shù)據(jù)的時(shí)候是引入零拷貝技術(shù)。
也就是說,直接讓操作系統(tǒng)的 Cache 中的數(shù)據(jù)發(fā)送到網(wǎng)卡后傳輸給下游的消費(fèi)者,中間跳過了兩次拷貝數(shù)據(jù)的步驟,Socket 緩存中僅僅會拷貝一個(gè)描述符過去,不會拷貝數(shù)據(jù)到 Socket 緩存。
大家看下圖,體會一下這個(gè)精妙的過程:
通過零拷貝技術(shù),就不需要把 OS Cache 里的數(shù)據(jù)拷貝到應(yīng)用緩存,再從應(yīng)用緩存拷貝到 Socket 緩存了,兩次拷貝都省略了,所以叫做零拷貝。
對 Socket 緩存僅僅就是拷貝數(shù)據(jù)的描述符過去,然后數(shù)據(jù)就直接從 OS Cache 中發(fā)送到網(wǎng)卡上去了,這個(gè)過程大大的提升了數(shù)據(jù)消費(fèi)時(shí)讀取文件數(shù)據(jù)的性能。
而且大家會注意到,在從磁盤讀數(shù)據(jù)的時(shí)候,會先看看 OS Cache 內(nèi)存中是否有,如果有的話,其實(shí)讀數(shù)據(jù)都是直接讀內(nèi)存的。
如果 Kafka 集群經(jīng)過良好的調(diào)優(yōu),大家會發(fā)現(xiàn)大量的數(shù)據(jù)都是直接寫入 OS Cache 中,然后讀數(shù)據(jù)的時(shí)候也是從 OS Cache 中讀。
相當(dāng)于是 Kafka 完全基于內(nèi)存提供數(shù)據(jù)的寫和讀了,所以這個(gè)整體性能會極其的高。
說個(gè)題外話,下回有機(jī)會給大家說一下 Elasticsearch 的架構(gòu)原理,其實(shí) ES 底層也是大量基于 OS Cache 實(shí)現(xiàn)了海量數(shù)據(jù)的高性能檢索的,跟 Kafka 原理類似。
總結(jié)
通過這篇文章對 Kafka 底層的頁緩存技術(shù)的使用,磁盤順序?qū)懙乃悸?,以及零拷貝技術(shù)的運(yùn)用,大家應(yīng)該就明白 Kafka 每臺機(jī)器在底層對數(shù)據(jù)進(jìn)行寫和讀的時(shí)候采取的是什么樣的思路,為什么它的性能可以那么高,做到每秒幾十萬的吞吐量。
這種設(shè)計(jì)思想對我們平時(shí)自己設(shè)計(jì)中間件的架構(gòu),或者是出去面試的時(shí)候,都有很大的幫助。
中華石杉:十余年 BAT 架構(gòu)經(jīng)驗(yàn),一線互聯(lián)網(wǎng)公司技術(shù)總監(jiān)。帶領(lǐng)上百人團(tuán)隊(duì)開發(fā)過多個(gè)億級流量高并發(fā)系統(tǒng)?,F(xiàn)將多年工作中積累下的研究手稿、經(jīng)驗(yàn)總結(jié)整理成文,傾囊相授。微信公眾號:石杉的架構(gòu)筆記(ID:shishan100)。