面試一線網際網路大廠？那這道題目你必須得會！
1、面試官為啥要出這樣一個開放式問題
這篇文章簡單給大家來聊一個網際網路大廠的Java面試題：如果讓你設計一個訊息中介軟體，你會怎麼做？
其實這個問題之前大致給大家聊過，本質就是面試官在考察一個高階以上的Java工程師的系統設計能力。
給你一個平時大家都常用的一個訊息中介軟體作為命題，讓你現場開放式發揮，立馬開動腦筋說說如果讓你來設計這麼一個訊息中介軟體。
讓你從整體架構，核心流程，資料結構，等各個層面來考慮，你會如何完成這個設計？
其實任何一個面試官都應該知道，如果一個人沒有真的做過訊息中介軟體開發的話，是不太可能在短時間內，瞬間給出一套特別靠譜的架構設計方案的。
但是用這個題目作為一個開放式命題，他最大的好處，就是可以儘可能的挖掘出一個候選人的較為真實的系統設計的能力和功底。
為什麼這麼說呢？
因為如果面試的時候很多東西都是一些常見的技術問題，比如說：
訊息中介軟體如何保證資料不丟失？
聊聊Elasticsearch的架構原理以及效能優化？
你們公司的微服務架構整體如何設計的？
這些問題相對來說都是比較固定的一些問題。
所謂固定的問題，就是隻要你花費一些時間去學習了相關的技術，或者是在自己所在的公司確實有過一些落地的經驗，通常來說回答出這些問題就不是太大的問題了。
但是這些問題都不夠開放，如果兩個候選人都同樣具備常規問題的回答能力，那麼此時通過一道有深度的開放式問題，就可以把幾個人裡迅速拉開差距，找出來到底誰的技術功底更加深厚，誰的架構設計能力更加強。
那麼本文就從各個角度來引導大家去思考一下，假如讓你回答這個問題，你可以從哪些方面入手來現場做一些考慮和回答？
2、生產消費模型以及核心資料結構
首先第一個點，訊息中介軟體本身要做的就是可以允許有人來生產訊息，還可以允許有人來消費這個訊息。
那麼這裡要考慮的第一個點，就是訊息中介軟體自己本身的核心資料結構。
也就是說，如果有人生產了訊息，你作為一個訊息中介軟體，應該如何儲存這個資料？
你會儲存在記憶體裡呢？還是儲存在磁碟檔案裡呢？或者兩者都同時共存？
可以先允許資料寫入記憶體作為一個緩衝，然後每隔幾秒再把資料刷入磁碟檔案中？資料刷入磁碟檔案之後，這個磁碟檔案有多少個？
你總不能一直搞一個磁碟檔案來存放所有的資料吧？那麼按照什麼樣的規則對磁碟檔案做一個拆分？
資料寫入磁碟檔案之後，是不是要有相應的一些metadata來標識這個資料的具體資訊？比如這個資料的offset偏移量，或者是一個內建的唯一id？
接著現在資料是被儲存在磁碟檔案裡了，那麼此時你如何把資料投遞到下游的消費者裡去呢？
你的消費模型是什麼樣的？比如說一個queue裡的資料，是會均勻分配給消費者的各個例項呢？還是會怎麼做呢？
在這裡給大家做一個提示，建議大家可以去研究研究比如kafka底層的檔案儲存原理，那是非常經典的高效能高併發訊息中介軟體儲存架構的實現。
另外就是可以參考一下rabbitmq和kafka的官網，研究一下不同中介軟體的消費模型是怎麼做的。
3、支撐TB級資料寫入的分散式架構
接著你應該考慮第二個大的問題，就是你的訊息中介軟體肯定會遇到每天TB級海量資料高併發高吞吐寫入的場景。
此時，你的訊息中介軟體的架構如何支撐呢？
所以這裡你就要考慮一下，你的資料是不是要分散式的儲存 ？
比如說假如你一天寫入幾百TB的資料，那不可能都放在一臺機器上吧？所以資料的分散式儲存是不是你要考慮的另外一個很重要的問題？
你是不是要考慮把一個大的資料集合做分片儲存，比如說分成N片資料，每個資料分片放在一臺機器上，這樣就可以充分利用多臺機器的資源來承載TB級的大量資料了。
此外你還需要考慮，你的資料分片是不是要可以支撐擴容？
比如你一開始設定的分片數量是10個，存在10臺機器上。結果現在發現10臺機器都扛不住了，需要擴容到20個分片，放在20臺機器上才可以。
那你是不是要支援資料分片的擴容以及自動資料負載均衡遷移？也就是10個分片的資料自動均勻分配給擴容後的20個分片。
所以這種分散式以及可伸縮的架構，是另外一個非常核心的點。
我個人同樣比較建議大家研究一下kafka在這塊的架構設計，非常的優秀，採用了partition的概念實現資料分片，支援分散式的資料儲存，而且還支援動態擴容。
4、資料宕機場景下的高可用架構
大家此時就要考慮另外一個問題了，就是一旦資料分散式儲存之後，那麼每臺機器上都有一部分資料。
萬一這臺機器宕機了呢？那麼資料是不是就丟失了？
是的！所以高可用的架構在這裡就必須考慮到了。
一般分散式系統實現高可用架構，都是採用多副本冗餘機制
也就是說一份資料在多臺機器上都搞一個副本，這樣任何一臺機器宕機了，資料肯定不會丟失，你還可以繼續使用其他機器上的副本資料來支援生產和消費。
同樣建議大家，研究一下kafka的多副本冗餘機制，他的每個partition資料分片都是有多個副本的，任何一臺機器宕機，丟失一個數據分片，還有其他機器上的副本分片在，可以支援資料不丟失。
5、支援資料不丟失的ack機制
最後再考慮一個問題，你的訊息中介軟體肯定是要支援資料絕對不丟失的吧？
那麼你必須要支援生產端和消費端的ack機制在這裡你必須考慮兩塊ack機制，一個是生產端，一旦投遞了訊息，必須要求他將資料比如寫入多個副本之後，才返回一個ack回撥響應。
否則要是一直沒收到ack的話，就需要重發一條訊息過去，保證生產投遞成功。
另外一個是消費端，一旦消費處理成功一條訊息了，必須返回一個ack給訊息中介軟體，然後訊息中介軟體才能刪除這條訊息。
否則一旦消費者宕機，就必須重發這條訊息給其他的消費者例項，保證訊息一定會被處理成功。
這塊如果大家不清楚，建議一定重看之前的系列文章，我們基於rabbitmq來闡述的這個資料不丟失的全鏈路ack機制。
6、最後的總結
這種開放式面試題，牽扯了大量的底層細節和架構思想，非常區分不同人的技術水平。如果你往簡單了回答，就本文涉及到的一些東西簡單說一說，基本也能過關。
但是如果你想技壓群雄，就必須要根據本文每個部分提示的東西，真的去對各種MQ中介軟體的底層原始碼進行深入的研究，然後才能在回答這個問題的時候，展現出“碾壓其他人”的技術功底和架構實力。我這邊整理了一套完整的面試資料和不會被輕視的架構知識，加群712477306立即獲取，希望可以幫到還在為工作煩擾的你們。
End