面試官：消息中間件如何實現每秒幾十萬的高併發寫入？【石杉的架構筆記】

歡迎關注我的公衆號：石杉的架構筆記（ID:shishan100）

週一至週五早8點半！精品技術文章準時送上！

精品學習資料獲取通道，參見文末

目錄

一、頁緩存技術 + 磁盤順序寫

二、零拷貝技術

三、最後的總結

「 這篇文章來聊一下Kafka的一些架構設計原理，這也是互聯網公司面試時很是高頻的技術考點。

Kafka是高吞吐低延遲的高併發、高性能的消息中間件，在大數據領域有極爲普遍的運用。配置良好的Kafka集羣甚至能夠作到每秒幾十萬、上百萬的超高併發寫入。

那麼Kafka究竟是如何作到這麼高的吞吐量和性能的呢？這篇文章咱們來一點一點說一下。

一、頁緩存技術 + 磁盤順序寫

首先Kafka每次接收到數據都會往磁盤上去寫，以下圖所示。

那麼在這裏咱們不由有一個疑問了，若是把數據基於磁盤來存儲，頻繁的往磁盤文件裏寫數據，這個性能會不會不好？你們確定都以爲磁盤寫性能是極差的。

沒錯，要是真的跟上面那個圖那麼簡單的話，那確實這個性能是比較差的。

可是實際上Kafka在這裏有極爲優秀和出色的設計，就是爲了保證數據寫入性能，首先Kafka是基於操做系統的頁緩存來實現文件寫入的。

操做系統自己有一層緩存，叫作page cache，是在內存裏的緩存，咱們也能夠稱之爲os cache，意思就是操做系統本身管理的緩存。

你在寫入磁盤文件的時候，能夠直接寫入這個os cache裏，也就是僅僅寫入內存中，接下來由操做系統本身決定何時把os cache裏的數據真的刷入磁盤文件中。

僅僅這一個步驟，就能夠將磁盤文件寫性能提高不少了，由於其實這裏至關因而在寫內存，不是在寫磁盤，你們看下圖。

接着另一個就是kafka寫數據的時候，很是關鍵的一點，他是以磁盤順序寫的方式來寫的。也就是說，僅僅將數據追加到文件的末尾，不是在文件的隨機位置來修改數據。

普通的機械磁盤若是你要是隨機寫的話，確實性能極差，也就是隨便找到文件的某個位置來寫數據。

可是若是你是追加文件末尾按照順序的方式來寫數據的話，那麼這種磁盤順序寫的性能基本上能夠跟寫內存的性能自己也是差很少的。

因此你們就知道了，上面那個圖裏，Kafka在寫數據的時候，一方面基於了os層面的page cache來寫數據，因此性能很高，本質就是在寫內存罷了。

另一個，他是採用磁盤順序寫的方式，因此即便數據刷入磁盤的時候，性能也是極高的，也跟寫內存是差很少的。

基於上面兩點，kafka就實現了寫入數據的超高性能。

那麼你們想一想，假如說kafka寫入一條數據要耗費1毫秒的時間，那麼是否是每秒就是能夠寫入1000條數據？

可是假如kafka的性能極高，寫入一條數據僅僅耗費0.01毫秒呢？那麼每秒是否是就能夠寫入10萬條數？

因此要保證每秒寫入幾萬甚至幾十萬條數據的核心點，就是盡最大可能提高每條數據寫入的性能，這樣就能夠在單位時間內寫入更多的數據量，提高吞吐量。

二、零拷貝技術

說完了寫入這塊，再來談談消費這塊。

你們應該都知道，從Kafka裏咱們常常要消費數據，那麼消費的時候實際上就是要從kafka的磁盤文件裏讀取某條數據而後發送給下游的消費者，以下圖所示。

那麼這裏若是頻繁的從磁盤讀數據而後發給消費者，性能瓶頸在哪裏呢？

假設要是kafka什麼優化都不作，就是很簡單的從磁盤讀數據發送給下游的消費者，那麼大概過程以下所示：

先看看要讀的數據在不在os cache裏，若是不在的話就從磁盤文件裏讀取數據後放入os cache。

接着從操做系統的os cache裏拷貝數據到應用程序進程的緩存裏，再從應用程序進程的緩存裏拷貝數據到操做系統層面的Socket緩存裏，最後從Socket緩存裏提取數據後發送到網卡，最後發送出去給下游消費。

整個過程，以下圖所示：

你們看上圖，很明顯能夠看到有兩次不必的拷貝吧！

一次是從操做系統的cache裏拷貝到應用進程的緩存裏，接着又從應用程序緩存裏拷貝回操做系統的Socket緩存裏。

並且爲了進行這兩次拷貝，中間還發生了好幾回上下文切換，一下子是應用程序在執行，一下子上下文切換到操做系統來執行。

因此這種方式來讀取數據是比較消耗性能的。

Kafka爲了解決這個問題，在讀數據的時候是引入零拷貝技術。

也就是說，直接讓操做系統的cache中的數據發送到網卡後傳輸給下游的消費者，中間跳過了兩次拷貝數據的步驟，Socket緩存中僅僅會拷貝一個描述符過去，不會拷貝數據到Socket緩存。

你們看下圖，體會一下這個精妙的過程：

經過零拷貝技術，就不須要把os cache裏的數據拷貝到應用緩存，再從應用緩存拷貝到Socket緩存了，兩次拷貝都省略了，因此叫作零拷貝。

對Socket緩存僅僅就是拷貝數據的描述符過去，而後數據就直接從os cache中發送到網卡上去了，這個過程大大的提高了數據消費時讀取文件數據的性能。

並且你們會注意到，在從磁盤讀數據的時候，會先看看os cache內存中是否有，若是有的話，其實讀數據都是直接讀內存的。

若是kafka集羣通過良好的調優，你們會發現大量的數據都是直接寫入os cache中，而後讀數據的時候也是從os cache中讀。

至關因而Kafka徹底基於內存提供數據的寫和讀了，因此這個總體性能會極其的高。

說個題外話

，下回有機會給你們說一下Elasticsearch的架構原理，其實ES底層也是大量基於os cache實現了海量數據的高性能檢索的，跟Kafka原理相似。

三、最後的總結

經過這篇文章對kafka底層的頁緩存技術的使用，磁盤順序寫的思路，以及零拷貝技術的運用，你們應該就明白Kafka每臺機器在底層對數據進行寫和讀的時候採起的是什麼樣的思路，爲何他的性能能夠那麼高，作到每秒幾十萬的吞吐量。

這種設計思想對咱們平時本身設計中間件的架構，或者是出去面試的時候，都有很大的幫助。

End

（封面圖源網絡，侵權刪除）

掃描下方二維碼，備註：「資料」，獲取更多「祕製」 精品學習資料

一大波微服務、分佈式、高併發、高可用的原創系列文章正在路上

歡迎掃描下方二維碼，持續關注：

石杉的架構筆記（id:shishan100）

十餘年BAT架構經驗傾囊相授

推薦閱讀：

一、拜託！面試請不要再問我Spring Cloud底層原理

二、【雙11狂歡的背後】微服務註冊中心如何承載大型系統的千萬級訪問？

三、【性能優化之道】每秒上萬併發下的Spring Cloud參數優化實戰

四、微服務架構如何保障雙11狂歡下的99.99%高可用

五、兄弟，用大白話告訴你小白都能聽懂的Hadoop架構原理

六、大規模集羣下Hadoop NameNode如何承載每秒上千次的高併發訪問

七、【性能優化的祕密】Hadoop如何將TB級大文件的上傳性能優化上百倍

八、拜託，面試請不要再問我TCC分佈式事務的實現原理！

九、【坑爹呀！】最終一致性分佈式事務如何保障實際生產中99.99%高可用？

十、拜託，面試請不要再問我Redis分佈式鎖的實現原理！

十一、【眼前一亮！】看Hadoop底層算法如何優雅的將大規模集羣性能提高10倍以上？

十二、億級流量系統架構之如何支撐百億級數據的存儲與計算

1三、億級流量系統架構之如何設計高容錯分佈式計算系統

1四、億級流量系統架構之如何設計承載百億流量的高性能架構

1五、億級流量系統架構之如何設計每秒十萬查詢的高併發架構

1六、億級流量系統架構之如何設計全鏈路99.99%高可用架構

1七、七張圖完全講清楚ZooKeeper分佈式鎖的實現原理

1八、大白話聊聊Java併發面試問題之volatile究竟是什麼？

1九、大白話聊聊Java併發面試問題之Java 8如何優化CAS性能？

20、大白話聊聊Java併發面試問題之談談你對AQS的理解？

2一、大白話聊聊Java併發面試問題之公平鎖與非公平鎖是啥？

2二、大白話聊聊Java併發面試問題之微服務註冊中心的讀寫鎖優化

2三、互聯網公司的面試官是如何360°無死角考察候選人的？（上篇）

2四、互聯網公司面試官是如何360°無死角考察候選人的？（下篇）

2五、Java進階面試系列之一：哥們，大家的系統架構中爲何要引入消息中間件？

2六、【Java進階面試系列之二】：哥們，那你說說系統架構引入消息中間件有什麼缺點？

2七、【行走的Offer收割機】記一位朋友斬獲BAT技術專家Offer的面試經歷

2八、【Java進階面試系列之三】哥們，消息中間件在大家項目裏是如何落地的？

2九、【Java進階面試系列之四】扎心！線上服務宕機時，如何保證數據100%不丟失？

30、一次JVM FullGC的背後，竟隱藏着驚心動魄的線上生產事故！

3一、【高併發優化實踐】10倍請求壓力來襲，你的系統會被擊垮嗎？

3二、【Java進階面試系列之五】消息中間件集羣崩潰，如何保證百萬生產數據不丟失？

3三、億級流量系統架構之如何在上萬併發場景下設計可擴展架構（上）？

3四、億級流量系統架構之如何在上萬併發場景下設計可擴展架構（中）？

3五、億級流量系統架構之如何在上萬併發場景下設計可擴展架構（下）？

3六、億級流量架構第二彈：你的系統真的無懈可擊嗎？

3七、億級流量系統架構之如何保證百億流量下的數據一致性（上）

3八、億級流量系統架構之如何保證百億流量下的數據一致性（中）？

3九、億級流量系統架構之如何保證百億流量下的數據一致性（下）？

40、互聯網面試必殺：如何保證消息中間件全鏈路數據100%不丟失（1）

4一、互聯網面試必殺：如何保證消息中間件全鏈路數據100%不丟失（2）

4二、面試大殺器：消息中間件如何實現消費吞吐量的百倍優化？

4三、高併發場景下，如何保證生產者投遞到消息中間件的消息不丟失？

4四、兄弟，用大白話給你講小白都能看懂的分佈式系統容錯架構

4五、從團隊自研的百萬併發中間件系統的內核設計看Java併發性能優化

4六、【非廣告，純乾貨】英語差的程序員如何才能無障礙閱讀官方文檔？

4七、若是20萬用戶同時訪問一個熱點緩存，如何優化你的緩存架構？

4八、【非廣告，純乾貨】中小公司的Java工程師應該如何逆襲衝進BAT？

4九、拜託，面試請不要再問我分佈式搜索引擎的架構原理！

50、【金三銀四跳槽季】Java工程師如何在1個月內作好面試準備？

5一、【offer收割機必備】我簡歷上的Java項目都好low，怎麼辦？

5二、【offer去哪了】我一連面試了十個Java崗，通通石沉大海！

5三、高階Java開發必備：分佈式系統的惟一id生成算法你瞭解嗎？

5四、支撐日活百萬用戶的高併發系統，應該如何設計其數據庫架構？

5五、尷尬了！Spring Cloud微服務註冊中心Eureka 2.x中止維護了咋辦？

5六、【Java高階必備】如何優化Spring Cloud微服務註冊中心架構？

做者：石杉的架構筆記 連接：https://juejin.im/post/5c6a9f25518825787e69e70a 來源：掘金 著做權歸做者全部。商業轉載請聯繫做者得到受權，非商業轉載請註明出處。