如果讓你寫一個消息隊列,該如何進行架構設計?

面試題

如果讓你寫一個消息隊列,該如何進行架構設計?說一下你的思路。

面試官心理分析

其實聊到這個問題,一般面試官要考察兩塊:

  • 你有沒有對某一個消息隊列做過較爲深入的原理的瞭解,或者從整體瞭解把握住一個消息隊列的架構原理。

  • 看看你的設計能力,給你一個常見的系統,就是消息隊列系統,看看你能不能從全局把握一下整體架構設計,給出一些關鍵點出來。

說實話,問類似問題的時候,大部分人基本都會蒙,因爲平時從來沒有思考過類似的問題,大多數人就是平時埋頭用,從來不去思考背後的一些東西。類似的問題,比如,如果讓你來設計一個 Spring 框架你會怎麼做?如果讓你來設計一個 Dubbo 框架你會怎麼做?如果讓你來設計一個 MyBatis 框架你會怎麼做?

面試題剖析

其實回答這類問題,說白了,不求你看過那技術的源碼,起碼你要大概知道那個技術的基本原理、核心組成部分、基本架構構成,然後參照一些開源的技術把一個系統設計出來的思路說一下就好。


比如說這個消息隊列系統,我們從以下幾個角度來考慮一下:

  • 首先這個 mq 得支持可伸縮性吧,就是需要的時候快速擴容,就可以增加吞吐量和容量,那怎麼搞?設計個分佈式的系統唄,參照一下 kafka 的設計理念,broker -> topic -> partition,每個 partition 放一個機器,就存一部分數據。如果現在資源不夠了,簡單啊,給 topic 增加 partition,然後做數據遷移,增加機器,不就可以存放更多數據,提供更高的吞吐量了?


  • 其次你得考慮一下這個 mq 的數據要不要落地磁盤吧?那肯定要了,落磁盤才能保證別進程掛了數據就丟了。那落磁盤的時候怎麼落啊?順序寫,這樣就沒有磁盤隨機讀寫的尋址開銷,磁盤順序讀寫的性能是很高的,這就是 kafka 的思路。


  • 其次你考慮一下你的 mq 的可用性啊?這個事兒,具體參考之前可用性那個環節講解的 kafka 的高可用保障機制。多副本 -> leader & follower -> broker 掛了重新選舉 leader 即可對外服務。


  • 能不能支持數據 0 丟失啊?可以的,參考我們之前說的那個 kafka 數據零丟失方案。

mq 肯定是很複雜的,面試官問你這個問題,其實是個開放題,他就是看看你有沒有從架構角度整體構思和設計的思維以及能力。確實這個問題可以刷掉一大批人,因爲大部分人平時不思考這些東西。


免費Java資料需要自己領取,涵蓋了Java、Redis、MongoDB、MySQL、Zookeeper、Spring Cloud、Dubbo/Kafka、Hadoop、Hbase、Flink等高併發分佈式、大數據、機器學習等技術。
傳送門:mp.weixin.qq.com/s/Jzdd


發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章