其實聊到這個問題，一般面試官要考察兩塊：
你有沒有對某乙個訊息佇列做過較為深入的原理的了解，或者從整體了解把握住乙個訊息佇列的架構原理。看看你的設計能力，給你乙個常見的系統，就是訊息佇列系統，看看你能不能從全域性把握一下整體架構設計，給出一些關鍵點出來。
說實話，問類似問題的時候，大部分人基本都會蒙，因為平時從來沒有思考過類似的問題，大多數人就是平時埋頭用，從來不去思考背後的一些東西。類似的問題，比如，如果讓你來設計乙個 spring 框架你會怎麼做？如果讓你來設計乙個 dubbo 框架你會怎麼做？如果讓你來設計乙個 mybatis 框架你會怎麼做？
其實回答這類問題，說白了，不求你看過那技術的原始碼，起碼你要大概知道那個技術的基本原理、核心組成部分、基本架構構成，然後參照一些開源的技術把乙個系統設計出來的思路說一下就好。
比如說這個訊息佇列系統，我們從以下幾個角度來考慮一下：
首先這個訊息佇列得支援可伸縮性吧，就是需要的時候快速擴容，就可以增加吞吐量和容量，那怎麼搞？設計個分布式的系統唄，參照一下 kafka 的設計理念，broker->topic->partition，每個partition放乙個機器，就存一部分資料。如果現在資源不夠了，簡單啊，給topic增加partition，然後做資料遷移，增加機器，不就可以存放更多資料，提供更高的吞吐量了？
其次你得考慮一下這個訊息佇列的資料要不要落地磁碟吧？那肯定要了，落地磁碟才能保證程序掛了資料不丟失。那落磁碟的時候怎麼落啊？順序寫，這樣就沒有磁碟隨機讀寫的定址開銷，磁碟順序讀寫的效能是很高的，這就是 kafka 的思路。
其次你考慮一下你的訊息佇列的可用性啊？這個事兒，具體參考之前如何保證訊息佇列的高可用講解的 kafka 的高可用保障機制。多副本 ->leader&follower->broker掛了重新選舉leader即可對外服務。
能不能支援資料 0 丟失啊？可以的，參考如何保證訊息的可靠性傳輸說的那個 kafka 資料零丟失方案。
訊息佇列肯定是很複雜的，面試官問你這個問題，其實是個開放題，他就是看看你有沒有從架構角度整體構思和設計的思維以及能力。確實這個問題可以刷掉一大批人，因為大部分人平時不思考這些東西。
該如何進行架構設計乙個MQ訊息佇列
如果讓你寫乙個訊息佇列，說一下你的思路。其實聊到這個問題，一般面試官要考察兩塊 說實話，問類似問題的時候，大部分人基本都會蒙，因為平時從來沒有思考過類似的問題，大多數人就是平時埋頭用，從來不去思考背後的一些東西。類似的問題，比如，如果讓你來設計乙個 spring 框架你會怎麼做？如果讓你來設計乙個 ...
用 Promise 實現乙個訊息佇列
在此篇部落格中，我們的需求如下 有乙個訊息排程器去操作傳送來訊息 但處理訊息花費的事件是不確定的，有多有少 訊息是不斷傳送過來的 這個時候就會出現一種情況 前一條訊息還未執行結束，後一條訊息就被傳送過來了 如果這個時候要求後一條訊息必須在前一條執行完才開始執行，該如何實現？sync function...
佇列演算法題 如何設計乙個排序系統
設計乙個排隊序列，能夠讓每個進入隊伍的使用者看到自己在佇列中所處的位置和變化，隊伍中隨時有人加入和退出 當有人退出影響到使用者排名時，需要及時的反饋。解析 既然是排隊序列，那麼加入只能排在隊尾。所以，他不會影響到原先所有人的排序。但是，有人退出時需要注意，隊頭的人和隊中間的人退出才會影響使用者排名，...