消息隊列的面試題1
問題：
為什么使用消息隊列啊？消息隊列有什么優點和缺點啊？kafka、activemq、rabbitmq、rocketmq都有什么區別以及適合哪些場景？
1.為什么使用消息隊列啊？
通用回答是：我們公司有個什么業務場景，這個業務場景有個什么技術挑戰，如果不用MQ可能會很麻煩，但是你現在用了MQ之后帶給了你很多的好處。
比較核心的有3個業務場景：解耦、異步、削峰
解耦：現場畫個圖來說明一下，A系統發送個數據到BCD三個系統，接口調用發送，那如果E系統也要這個數據呢？那如果C系統現在不需要了呢？現在A系統又要發送第二種數據了呢？A系統負責人瀕臨崩潰中。。。再來點更加崩潰的事兒，A系統要時時刻刻考慮BCDE四個系統如果掛了咋辦？我要不要重發？我要不要把消息存起來？頭發都白了啊。。。
不用MQ的系統耦合場景：
使用了MQ之后的解耦場景：
異步：現場畫個圖來說明一下，A系統接收一個請求，需要在自己本地寫庫，還需要在BCD三個系統寫庫，自己本地寫庫要3ms，BCD三個系統分別寫庫要300ms、450ms、200ms。最終請求總延時是3 + 300 + 450 + 200 = 953ms，接近1s，用戶感覺搞個什么東西，慢死了慢死了。
不用MQ的同步高延時請求場景：
使用了MQ進行異步之后的接口性能優化：
削峰：每天0點到11點，A系統風平浪靜，每秒並發請求數量就100個。結果每次一到11點~1點，每秒並發請求數量突然會暴增到1萬條。但是系統最大的處理能力就只能是每秒鍾處理1000個請求啊。。。尷尬了，系統會死。。。
沒用MQ高峰期系統被打死的場景：
使用MQ來進行削峰的場景：
（2）消息隊列有什么優點和缺點啊？
優點上面已經說了，就是在特殊場景下有其對應的好處，解耦、異步、削峰
缺點呢？顯而易見的
系統可用性降低：系統引入的外部依賴越多，越容易掛掉，本來你就是A系統調用BCD三個系統的接口就好了，人ABCD四個系統好好的，沒啥問題，你偏加個MQ進來，萬一MQ掛了咋整？MQ掛了，整套系統崩潰了，你不就完了么。
系統復雜性提高：硬生生加個MQ進來，你怎么保證消息沒有重復消費？怎么處理消息丟失的情況？怎么保證消息傳遞的順序性？頭大頭大，問題一大堆，痛苦不已
一致性問題：A系統處理完了直接返回成功了，人都以為你這個請求就成功了；但是問題是，要是BCD三個系統那里，BD兩個系統寫庫成功了，結果C系統寫庫失敗了，咋整？你這數據就不一致了。
所以消息隊列實際是一種非常復雜的架構，你引入它有很多好處，但是也得針對它帶來的壞處做各種額外的技術方案和架構來規避掉，最好之后，你會發現，媽呀，系統復雜度提升了一個數量級，也許是復雜了10倍。但是關鍵時刻，用，還是得用的。。。
（3）kafka、activemq、rabbitmq、rocketmq都有什么優點和缺點啊？
優劣勢總結:
ActiveMQ:
非常成熟，功能強大，在業內大量的公司以及項目中都有應用
偶爾會有較低概率丟失消息
而且現在社區以及國內應用都越來越少，官方社區現在對ActiveMQ 5.x維護越來越少，幾個月才發布一個版本
而且確實主要是基於解耦和異步來用的，較少在大規模吞吐的場景中使用
RabbitMQ:
erlang語言開發，性能極其好，延時很低；
吞吐量到萬級，MQ功能比較完備
而且開源提供的管理界面非常棒，用起來很好用
社區相對比較活躍，幾乎每個月都發布幾個版本分
在國內一些互聯網公司近幾年用rabbitmq也比較多一些
但是問題也是顯而易見的，RabbitMQ確實吞吐量會低一些，這是因為他做的實現機制比較重。
而且erlang開發，國內有幾個公司有實力做erlang源碼級別的研究和定制？如果說你沒這個實力的話，確實偶爾會有一些問題，你很難去看懂源碼，你公司對這個東西的掌控很弱，基本職能依賴於開源社區的快速維護和修復bug。
而且rabbitmq集群動態擴展會很麻煩，不過這個我覺得還好。其實主要是erlang語言本身帶來的問題。很難讀源碼，很難定制和掌控。
RocketMQ:
接口簡單易用，而且畢竟在阿里大規模應用過，有阿里品牌保障
日處理消息上百億之多，可以做到大規模吞吐，性能也非常好，分布式擴展也很方便，社區維護還可以，可靠性和可用性都是ok的，還可以支撐大規模的topic數量，支持復雜MQ業務場景
而且一個很大的優勢在於，阿里出品都是java系的，我們可以自己閱讀源碼，定制自己公司的MQ，可以掌控
社區活躍度相對較為一般，不過也還可以，文檔相對來說簡單一些，然后接口這塊不是按照標准JMS規范走的有些系統要遷移需要修改大量代碼
還有就是阿里出台的技術，你得做好這個技術萬一被拋棄，社區黃掉的風險，那如果你們公司有技術實力我覺得用RocketMQ挺好的
kafka:
kafka的特點其實很明顯，就是僅僅提供較少的核心功能，但是提供超高的吞吐量，ms級的延遲，極高的可用性以及可靠性，而且分布式可以任意擴展
同時kafka最好是支撐較少的topic數量即可，保證其超高吞吐量
而且kafka唯一的一點劣勢是有可能消息重復消費，那么對數據准確性會造成極其輕微的影響，在大數據領域中以及日志采集中，這點輕微影響可以忽略
這個特性天然適合大數據實時計算以及日志收集
綜上所述，各種對比之后，我個人傾向於是：
一般的業務系統要引入MQ，最早大家都用ActiveMQ，但是現在確實大家用的不多了，沒經過大規模吞吐量場景的驗證，社區也不是很活躍，所以大家還是算了吧，我個人不推薦用這個了；
后來大家開始用RabbitMQ，但是確實erlang語言阻止了大量的java工程師去深入研究和掌控他，對公司而言，幾乎處於不可控的狀態，但是確實人是開源的，比較穩定的支持，活躍度也高；
不過現在確實越來越多的公司，會去用RocketMQ，確實很不錯，但是我提醒一下自己想好社區萬一突然黃掉的風險，對自己公司技術實力有絕對自信的，我推薦用RocketMQ，否則回去老老實實用RabbitMQ吧，人是活躍開源社區，絕對不會黃
所以中小型公司，技術實力較為一般，技術挑戰不是特別高，用RabbitMQ是不錯的選擇；大型公司，基礎架構研發實力較強，用RocketMQ是很好的選擇
如果是大數據領域的實時計算、日志采集等場景，用Kafka是業內標准的，絕對沒問題，社區活躍度很高，絕對不會黃，何況幾乎是全世界這個領域的事實性規范