應用場景
為什么使用消息隊列(面試官看你思不思考)
其實就是問問你消息隊列都有哪些使用場景，然后你項目里具體是什么場景，說說你在這個場景里用消息隊列是什么？
面試官問你這個問題，期望的一個回答是說，你們公司有個什么業務場景，這個業務場景有個什么技術挑戰，如果不用 MQ 可能會很麻煩，但是你現在用了 MQ 之后帶給了你很多的好處。
先說一下消息隊列常見的使用場景吧，其實場景有很多，但是比較核心的有 3 個：解耦、異步、削峰。
解耦
一個系統(模塊)調用多個系統(模塊)的場景
多個系統的添加或減少都需修改調用系統的代碼
且不需要同步調用接口的情況
異步
涉及到時間消耗問題,當一個信息傳入同時保存到多個系統,
期間需要一個時間消耗,
這時只需要信息先保存當前系統,剩下的放入消息隊列
削峰
每個系統性能都是有極限的
類似淘寶雙十一,數據量猛增,
這個時候就需要把用戶的請求放入消息隊列中,
每次從隊列中取出最大數據(剛好不會使系統崩潰的數據),
這樣請求就會堆積在消息隊列中,
等到閑時請求就少了,但系統人以最大吞吐去處理數據,
所以堆積消息很快會被解決
消息隊列的優缺點
優點
在特殊場景下有其對應的好處，解耦、異步、削峰。
缺點
-
系統可用性降低
系統引入的外部依賴越多,越容易掛掉.
MQ掛掉,全部涼涼
-
系統復雜度提高
如何保證消息沒有被重復消費
怎么處理消息丟失的情況
怎么保證消息的順序型
-
一致性問題
A 系統處理完了直接返回成功了，人都以為你這個請求就成功了；但是問題是，要是 BCD 三個系統那里，BD 兩個系統寫庫成功了，結果 C 系統寫庫失敗了，咋整？你這數據就不一致了。
Kafka、ActiveMQ、RabbitMQ、RocketMQ有什么優缺點？
| 特性 | ActiveMQ | RabbitMQ | RocketMQ | Kafka |
|---|---|---|---|---|
| 單機吞吐量 | 萬級，比 RocketMQ、Kafka 低一個數量級 | 同 ActiveMQ | 10 萬級，支撐高吞吐 | 10 萬級，高吞吐，一般配合大數據類的系統來進行實時數據計算、日志采集等場景 |
| topic 數量對吞吐量的影響 | topic 可以達到幾百/幾千的級別，吞吐量會有較小幅度的下降，這是 RocketMQ 的一大優勢，在同等機器下，可以支撐大量的 topic | topic 從幾十到幾百個時候，吞吐量會大幅度下降，在同等機器下，Kafka 盡量保證 topic 數量不要過多，如果要支撐大規模的 topic，需要增加更多的機器資源 | ||
| 時效性 | ms 級 | 微秒級，這是 RabbitMQ 的一大特點，延遲最低 | ms 級 | 延遲在 ms 級以內 |
| 可用性 | 高，基於主從架構實現高可用 | 同 ActiveMQ | 非常高，分布式架構 | 非常高，分布式，一個數據多個副本，少數機器宕機，不會丟失數據，不會導致不可用 |
| 消息可靠性 | 有較低的概率丟失數據 | 基本不丟 | 經過參數優化配置，可以做到 0 丟失 | 同 RocketMQ |
| 功能支持 | MQ 領域的功能極其完備 | 基於 erlang 開發，並發能力很強，性能極好，延時很低 | MQ 功能較為完善，還是分布式的，擴展性好 | 功能較為簡單，主要支持簡單的 MQ 功能，在大數據領域的實時計算以及日志采集被大規模使用 |
- 一般的業務系統要引入 MQ，最早大家都用 ActiveMQ，但是現在確實大家用的不多了，沒經過大規模吞吐量場景的驗證，社區也不是很活躍，所以大家還是算了吧，我個人不推薦用這個了；
- 后來大家開始用 RabbitMQ，但是確實 erlang 語言阻止了大量的 Java 工程師去深入研究和掌控它，對公司而言，幾乎處於不可控的狀態，但是確實人家是開源的，比較穩定的支持，活躍度也高；
- 不過現在確實越來越多的公司會去用 RocketMQ，確實很不錯，畢竟是阿里出品，但社區可能有突然黃掉的風險（目前 RocketMQ 已捐給 Apache，但 GitHub 上的活躍度其實不算高）對自己公司技術實力有絕對自信的，推薦用 RocketMQ，否則回去老老實實用 RabbitMQ 吧，人家有活躍的開源社區，絕對不會黃。
- 所以中小型公司，技術實力較為一般，技術挑戰不是特別高，用 RabbitMQ 是不錯的選擇；大型公司，基礎架構研發實力較強，用 RocketMQ 是很好的選擇。
- 如果是大數據領域的實時計算、日志采集等場景，用 Kafka 是業內標准的，絕對沒問題，社區活躍度很高，絕對不會黃，何況幾乎是全世界這個領域的事實性規范。