面試一線互聯網大廠？那這道題目你必須得會！

時間 2019-11-09

標籤面試一線互聯網大廠題目必須欄目快樂工作简体版

原文原文鏈接

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

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

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

一、面試官爲啥要出這樣一個開放式問題

這篇文章簡單給你們來聊一個互聯網大廠的Java面試題：若是讓你設計一個消息中間件，你會怎麼作？數據庫

其實這個問題以前大體給你們聊過，本質就是面試官在考察一個高級以上的Java工程師的系統設計能力。緩存

給你一個平時你們都經常使用的一個消息中間件做爲命題，讓你現場開放式發揮，立馬開動腦筋說說若是讓你來設計這麼一個消息中間件。性能優化

讓你從總體架構，核心流程，數據結構，等各個層面來考慮，你會如何完成這個設計？網絡

其實任何一個面試官都應該知道，若是一我的沒有真的作過消息中間件開發的話，是不太可能在短期內，瞬間給出一套特別靠譜的架構設計方案的。數據結構

可是用這個題目做爲一個開放式命題，他最大的好處，就是能夠儘量的挖掘出一個候選人的較爲真實的系統設計的能力和功底。架構

爲何這麼說呢？併發

由於若是面試的時候不少東西都是一些常見的技術問題，好比說：

消息中間件如何保證數據不丟失？
聊聊Elasticsearch的架構原理以及性能優化？
大家公司的微服務架構總體如何設計的？

這些問題相對來講都是比較固定的一些問題。

所謂固定的問題，就是隻要你花費一些時間去學習了相關的技術，或者是在本身所在的公司確實有過一些落地的經驗，一般來講回答出這些問題就不是太大的問題了。

可是這些問題都不夠開放，若是兩個候選人都一樣具有常規問題的回答能力，那麼此時經過一道有深度的開放式問題，就能夠把幾我的裏迅速拉開差距，找出來到底誰的技術功底更加深厚，誰的架構設計能力更增強。

那麼本文就從各個角度來引導你們去思考一下，假如讓你回答這個問題，你能夠從哪些方面入手來現場作一些考慮和回答？

二、生產消費模型以及核心數據結構

首先第一個點，消息中間件自己要作的就是能夠容許有人來生產消息，還能夠容許有人來消費這個消息。

那麼這裏要考慮的第一個點，就是消息中間件本身自己的核心數據結構。

也就是說，若是有人生產了消息，你做爲一個消息中間件，應該如何存儲這個數據？

你會存儲在內存裏呢？仍是存儲在磁盤文件裏呢？或者二者都同時共存？

能夠先容許數據寫入內存做爲一個緩衝，而後每隔幾秒再把數據刷入磁盤文件中？數據刷入磁盤文件以後，這個磁盤文件有多少個？

你總不能一直搞一個磁盤文件來存放全部的數據吧？那麼按照什麼樣的規則對磁盤文件作一個拆分？

數據寫入磁盤文件以後，是否是要有相應的一些metadata來標識這個數據的具體信息？好比這個數據的offset偏移量，或者是一個內置的惟一id？

接着如今數據是被存儲在磁盤文件裏了，那麼此時你如何把數據投遞到下游的消費者裏去呢？

你的消費模型是什麼樣的？好比說一個queue裏的數據，是會均勻分配給消費者的各個實例呢？仍是會怎麼作呢？

在這裏給你們作一個提示，建議你們能夠去研究研究好比kafka底層的文件存儲原理，那是很是經典的高性能高併發消息中間件存儲架構的實現。

另外就是能夠參考一下rabbitmq和kafka的官網，研究一下不一樣中間件的消費模型是怎麼作的。

三、支撐TB級數據寫入的分佈式架構

接着你應該考慮第二個大的問題，就是你的消息中間件確定會遇到天天TB級海量數據高併發高吞吐寫入的場景。

此時，你的消息中間件的架構如何支撐呢？

因此這裏你就要考慮一下，你的數據是否是要分佈式的存儲？

好比說假如你一天寫入幾百TB的數據，那不可能都放在一臺機器上吧？因此數據的分佈式存儲是否是你要考慮的另一個很重要的問題？

你是否是要考慮把一個大的數據集合作分片存儲，好比說分紅N片數據，每一個數據分片放在一臺機器上，這樣就能夠充分利用多臺機器的資源來承載TB級的大量數據了。

此外你還須要考慮，你的數據分片是否是要能夠支撐擴容？

好比你一開始設置的分片數量是10個，存在10臺機器上。結果如今發現10臺機器都扛不住了，須要擴容到20個分片，放在20臺機器上才能夠。

那你是否是要支持數據分片的擴容以及自動數據負載均衡遷移？也就是10個分片的數據自動均勻分配給擴容後的20個分片。

因此這種分佈式以及可伸縮的架構，是另一個很是核心的點。

我我的一樣比較建議你們研究一下kafka在這塊的架構設計，很是的優秀，採用了partition的概念實現數據分片，支持分佈式的數據存儲，並且還支持動態擴容。

四、數據宕機場景下的高可用架構

你們此時就要考慮另一個問題了，就是一旦數據分佈式存儲以後，那麼每臺機器上都有一部分數據。

萬一這臺機器宕機了呢？那麼數據是否是就丟失了？

是的！因此高可用的架構在這裏就必須考慮到了。

通常分佈式系統實現高可用架構，都是採用多副本冗餘機制

也就是說一份數據在多臺機器上都搞一個副本，這樣任何一臺機器宕機了，數據確定不會丟失，你還能夠繼續使用其餘機器上的副本數據來支持生產和消費。

一樣建議你們，研究一下kafka的多副本冗餘機制，他的每一個partition數據分片都是有多個副本的，任何一臺機器宕機，丟失一個數據分片，還有其餘機器上的副本分片在，能夠支持數據不丟失。

五、支持數據不丟失的ack機制

最後再考慮一個問題，你的消息中間件確定是要支持數據絕對不丟失的吧？

那麼你必需要支持生產端和消費端的ack機制，這塊內容咱們以前都用多篇文章講解過裏面的具體的原理，你們能夠參考一下：

在這裏你必須考慮兩塊ack機制，一個是生產端，一旦投遞了消息，必需要求他將數據好比寫入多個副本以後，才返回一個ack回調響應。

不然要是一直沒收到ack的話，就須要重發一條消息過去，保證生產投遞成功。

另一個是消費端，一旦消費處理成功一條消息了，必須返回一個ack給消息中間件，而後消息中間件才能刪除這條消息。

不然一旦消費者宕機，就必須重發這條消息給其餘的消費者實例，保證消息必定會被處理成功。

這塊若是你們不清楚，建議必定重看以前的系列文章，咱們基於rabbitmq來闡述的這個數據不丟失的全鏈路ack機制。

六、最後的總結

這種開放式面試題，牽扯了大量的底層細節和架構思想，很是區分不一樣人的技術水平。若是你往簡單了回答，就本文涉及到的一些東西簡單說一說，基本也能過關。

可是若是你想技壓羣雄，就必需要根據本文每一個部分提示的東西，真的去對各類MQ中間件的底層源碼進行深刻的研究，而後才能在回答這個問題的時候，展示出「碾壓其餘人」的技術功底和架構實力。

End

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

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

若有收穫，請幫忙轉發，您的鼓勵是做者最大的動力，謝謝！

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

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

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

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