阿竺 ·1. 前言
除了計算機網絡、操作系統等基礎知識的考察，各種流行的中間件也深受面試官的青睞。之前的章節已經對緩存中間件的代表 Redis 的面試題進行了分析，本章節將介紹常用的消息中間件，即 RabbitMQ 的基礎定義以及使用原因。
2. 消息隊列使用場景
面試官提問： 為什么要使用消息隊列？能說說消息隊列解決了什么問題？
題目解析：
任何工具都有誕生的背景，例如非關系型數據庫是為了解決性能以及擴展性問題產生。
常見的消息隊列有 RabbitMQ、RocketMQ、Kafka 等，消息隊列也是針對特定問題有不同的使用場景，可以抽象為異步處理、應用解耦、流量削峰三種場景。
2.1 異步處理 & 應用解耦
以最常見的在網站注冊新用戶場景為例，如果經過了基本的業務邏輯之后，要通過短信和郵件的方式驗證是否用戶本人注冊，每個流程的請求響應耗時為 100ms，在同步的方式下總共需要耗時 300ms。
?
其中發送驗證短信以及發送驗證郵件兩個步驟并沒有強制的先后依賴關系，所以同步請求的效率相對較低，使用消息隊列可以將驗證短信和郵件的模塊拆開，經過消息隊列中轉分發請求，假設消息隊列的讀寫時間為 20ms，總流程的耗時被優化到 220ms。
?
上述異步請求的過程本質上也是應用解耦的過程，最基礎的應用架構中可以將短信注冊模塊和郵件注冊模塊都可以耦合在注冊業務邏輯中，但是如果有其他的服務也需要使用短信注冊功能，就只能調用注冊業務的短信模塊接口。此時，程序的魯棒性相對較差，當注冊業務模塊的服務器宕機之后，會造成所有服務的短信模塊都不可用，所以需要將短信模塊解耦出來，同理，郵件模塊也需要被拆分為單獨的服務。候選人需要注意一點，這種拆分本質上都是為了應用服務的高可用。
2.2 流量削峰
互聯網存在很多高并發場景，例如在 12306 搶購春運火車票，或者阿里淘寶的雙十一秒殺活動，系統服務在短時間收到大量的用戶請求，如果數據庫不能抗住相對日常的 N 倍流量被打垮，會導致服務不可用。為了避免這種情況發生，有熔斷、降級、以及流量削峰等多種解決方案，消息隊列是最常見的流量削峰方案。
?
還是以用戶注冊的例子，例如在雙十一凌晨時間，大量新用戶通過活動鏈接進入了網站的注冊頁面，在收到用戶請后后，首先將請求寫入消息隊列，如果請求數量超過消息隊列的容量，那么多余的請求直接放棄并且跳轉到錯誤頁面，這也是常用的降級方案。
業務代碼從消息隊列中拿到用戶請求，再進行后續的業務邏輯。消息隊列在用戶和業務邏輯中之間作為中間件模塊，防止大量流量直接打到底層數據庫。
3. 常用消息隊列
面試官提問： 常用的消息隊列有哪些？
題目解析：
最常見的消息隊列有 ActiveMQ、RabbitMQ、RocketMQ 以及 Kafka，我們一般關注的是 RabbitMQ 以及 Kafka，我們關注基本定義以及兩者之間的特性差別。
- RabbitMQ：基于 Erlang 語言開發的消息發布和訂閱系統，基于 AMQP 協議實現。AMQP 協議一般在對數據一致性要求高、對性能要求較低的場景使用；
- Kafka：LinkedIn 公司開源的消息發布和訂閱系統，一般在對數據一致性要求較低、海量數據的處理場景中使用。
下面對比分析下兩種消息隊列的特性差異。
3.1 吞吐量對比
- RabbitMQ：單機吞吐量在萬級別，比 Kafka 低一個數量級；
- Kafka：單機吞吐量在十萬級別，數據的存儲和讀取都是依靠本地硬盤的順序讀寫，處理效率高。
3.2 應用場景對比
- RabbitMQ：企業內部微服務，例如內部人員管理系統的消息通訊場景。因為基于 Erlang 開發語言，對小型企業來說，開發維護成本相對較高；
- Kafka：大數據系統中常用，例如日志處理以及數據實時分析場景，目前 Kafka 幾乎是日志采集場景的首選消息隊列。
4. 小結
本章節介紹了消息隊列的基本使用場景，需要理解消息隊列的核心是異步處理以及解耦能力。我們對比了 RabbitMQ 和 Kafka 兩種消息隊列的特性，在后續的章節主要會對 RabbitMQ 的常見題目進行分析。
2025 imooc.com All Rights Reserved |