起碼你大概知道那個技術的基本原理，核心組成部分，基本架構構成，然後參照一些開源的技術把乙個系統設計出來的思路說一下就好
比如說這個訊息佇列系統，我們來從以下幾個角度來考慮一下
（1）首先這個mq得支援可伸縮性吧，就是需要的時候快速擴容，就可以增加吞吐量和容量，那怎麼搞？設計個分布式的系統唄，參照一下kafka的設計理念，broker -> topic -> partition，每個partition放乙個機器，就存一部分資料。如果現在資源不夠了，簡單啊，給topic增加partition，然後做資料遷移，增加機器，不就可以存放更多資料，提供更高的吞吐量了？
（2）其次你得考慮一下這個mq的資料要不要落地磁碟吧？那肯定要了，落磁碟，才能保證別程序掛了資料就丟了。那落磁碟的時候怎麼落啊？順序寫，這樣就沒有磁碟隨機讀寫的定址開銷，磁碟順序讀寫的效能是很高的，這就是kafka的思路。
（3）其次你考慮一下你的mq的可用性啊？這個事兒，具體參考我們之前可用性那個環節講解的kafka的高可用保障機制。多副本 -> leader & follower -> broker掛了重新選舉leader即可對外服務。
（4）能不能支援資料0丟失啊？可以的，參考我們之前說的那個kafka資料零丟失方案
其實乙個mq肯定是很複雜的，面試官問你這個問題，其實是個開放題，他就是看看你有沒有從架構角度整體構思和設計的思維以及能力。確實這個問題可以刷掉一大批人，因為大部分人平時不思考這些東西。
通過訊息佇列實現乙個程序寫資料，乙個程序讀資料
include include include include include include typedef struct msg msg intmain int argc,char ar msg id msgget key,ipc creat 0666 建立訊息佇列 if msg id 1 pr...
如何設計乙個訊息佇列
其實聊到這個問題，一般面試官要考察兩塊 你有沒有對某乙個訊息佇列做過較為深入的原理的了解，或者從整體了解把握住乙個訊息佇列的架構原理。看看你的設計能力，給你乙個常見的系統，就是訊息佇列系統，看看你能不能從全域性把握一下整體架構設計，給出一些關鍵點出來。說實話，問類似問題的時候，大部分人基本都會蒙，因...
訊息佇列面試解析系列（三） 訊息模型辨析
mq都得有訊息模型，就會產生比如佇列 queue 主題 topic 分割槽 partition 這些名詞，但是概念上卻不盡相同。因為沒有標準。曾經，也有一些國際組織嘗試制定訊息的標準，比如jms和amqp。但標準制定跟不上mq演進速度，這些標準名存實亡。好的架構不是設計出來的，而是演進出來的。現代m...