面試連環炮
- 你用過消息隊列麼？
- 說說你們項目裏是怎麼用消息隊列的？
- 我們有一個訂單系統，訂單系統會每次下一個新訂單的時候，就會發送一條消息到ActiveMQ裏面去，後臺有一個庫存系統，負責獲取消息，然後更新庫存。
- 爲什麼使用消息隊列？
- 你的訂單系統不發送消息到MQ，而是直接調用庫存系統的一個接口，然後直接調用成功了，庫存也更新了，那就不需要使用消息隊列了呀
- 使用消息隊列的主要作用是：異步、解耦、削峯
- 消息隊列都有什麼優缺點？
- Kafka、activeMQ、RibbitMQ、RocketMQ都有什麼優缺點？
- 如何保證消息隊列的高可用？
- 如何保證消息不被重複消費？如何保證消息消費時的冪等性？
- 如何保證消息的可靠性傳輸，要是消息丟失了怎麼辦？
- 如何保證消息的順序性？
- 如何解決消息隊列的延時以及過期失效問題？消息隊列滿了以後該怎麼處理？有幾百萬消息持續積壓幾小時，說說怎麼解決？
- 如果讓你寫一個消息隊列，該如何進行架構設計，說一下你的思路？
主流MQ包括：kafka、ActiveMQ、RabbitMQ和RocketMQ
常見的MQ其實就上面的四種
| 特性 | ActiveMQ | RabbitMQ | RocketMQ | Kafka |
|---|---|---|---|---|
| 單機吞吐量 | 萬級，吞吐量比RocketMQ和Kafka要低一個數量級 | 萬級，吞吐量比RocketMQ和Kafka要低一個數量級 | 10萬級，RocketMQ也是可以支撐高吞吐的一種MQ | 10萬級1這是kafka最大的優點，就是吞吐量高。一般配置和數據類的系統進行實時數據計算、日誌採集等場景 |
| 時效性 | ms級 | 微妙級，這是RabbitMQ的一大特點，就是延遲最低 | ms級 | 延遲在ms級內 |
| 可用性 | 基於主從架構實現高可用 | 高，基於主從架構實現高可用 | 非常高，分佈式架構 | 非常高，kafka是分佈式的，一個數據多個副本，少數機器宕機後，不會丟失數據，不會導致不可用 |
| 消息可靠性 | 有較低的概率丟失數據 | 消息不丟失 | 經過參數優化配置，可以做到0丟失 | 經過參數優化配置可以做到0丟失 |
| 核心特點 | MQ領域的功能及其完備 | 基於Erlang開發，所以併發能力強，性能及其好，延時很低 | MQ功能較爲完善，還是分佈式的，擴展性好 | 功能較爲簡單，主要支持簡單的MQ功能，在大數據領域的實時計算以及日誌採集被大規模使用，是實時上的標準。 |
| 非常成熟，功能強大，在業內大量公司以及項目都有應用。 但是偶爾消息丟失的概率，並且現在社區以及國內應用都越來越少，官方社區對ActiveMQ5.X維護越來越少，而且確實主要是基於解耦和異步來用的，較少在大規模吞吐場景中使用 | erlang語言開發的，性能及其好，延時很低。而且開源的版本，就提供的管理界面非常棒，在國內一些互聯網公司近幾年用RabbitMQ也是比較多一些，特別適用於中小型的公司 缺點顯而易見，就是吞吐量會低一些，這是因爲它做的實現機制比較中，因爲使用erlang開發，目前沒有多少公司使用其開發。所以針對源碼界別的定製，非常困難，因此公司的掌控非常弱，只能依賴於開源社區的維護。 | 接口簡單易用，畢竟在阿里大規模應用過，有阿里平臺保障，日處理消息上 百億之多，可以做到大規模吞吐，性能也非常好，分佈式擴展也很方便，社區維護還可以，可靠性和可用性都是OK的，還可以支撐大規模的topic數量，支持複雜MQ業務場景。 | 僅僅提供較少的核心功能，但是提供超高的吞吐量，ms級別的延遲，極高的可用性以及可靠性，分佈式可以任意擴展。 同時kafka最好是支撐較少的topic數量即可，保證其超高的吞吐量。 |
綜上所述：
- 一般的業務要引入MQ，最早大家都是用ACviceMQ，但是現在大家用的不多了，沒有經過大規模吞吐量場景的驗證，社區也不是很活躍，所以大家還是算了，不太圖鑑使用
- RabbitMQ後面被大量的中小型公司所使用，但是erlang語言阻礙了大量的Java工程師深入研究和掌握它，對公司而言，幾乎處於不可控的狀態，但是RabbitMQ目前開源穩定，活躍度也表較高。
- RocketMQ是阿里開源的一套消息中間件，目前也已經經歷了天貓雙十一，同時底層使用Java進行開發
如果中小型企業技術實力一般，技術挑戰不是很高，可以推薦，RabbitMQ。
如果公司的基礎研發能力很強，想精確到源碼級別的掌握，那麼推薦使用RocketMQ。
同時如果項目是聚焦於大數據領域的實時計算，日誌採集等場景，那麼Kafka是業內標準。