關於MQ的幾件小事(七)如果讓你設計一個MQ,你怎么設計


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

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

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

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

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

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

其實一個mq肯定是很復雜的,其實這是個開放題,就是看看你有沒有從架構角度整體構思和設計的思維以及能力。

如果你還不清楚,請參考前面幾篇
消息隊列的用途、優缺點、技術選型
如何保證消息隊列的高可用
如何保證消息不重復消費
如何防止數據隊列數據丟失
如何保證消息按順序執行
消息積壓在消息隊列里怎么辦


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM