主流MQ的對比

（1）爲何使用消息隊列啊？

 

其實就是問問你消息隊列都有哪些使用場景，而後你項目裏具體是什麼場景，說說你在這個場景裏用消息隊列是什麼

 

面試官問你這個問題，指望的一個回答是說，大家公司有個什麼業務場景，這個業務場景有個什麼技術挑戰，若是不用MQ可能會很麻煩，可是你如今用了MQ以後帶給了你不少的好處

 

先說一下消息隊列的常見使用場景吧，其實場景有不少，可是比較核心的有3個：解耦、異步、削峯

 

解耦：現場畫個圖來講明一下，A系統發送個數據到BCD三個系統，接口調用發送，那若是E系統也要這個數據呢？那若是C系統如今不須要了呢？如今A系統又要發送第二種數據了呢？A系統負責人瀕臨崩潰中。。。再來點更加崩潰的事兒，A系統要時時刻刻考慮BCDE四個系統若是掛了咋辦？我要不要重發？我要不要把消息存起來？頭髮都白了啊。。。

 

面試技巧：你須要去考慮一下你負責的系統中是否有相似的場景，就是一個系統或者一個模塊，調用了多個系統或者模塊，互相之間的調用很複雜，維護起來很麻煩。可是其實這個調用是不須要直接同步調用接口的，若是用MQ給他異步化解耦，也是能夠的，你就須要去考慮在你的項目裏，是否是能夠運用這個MQ去進行系統的解耦。在簡歷中體現出來這塊東西，用MQ做解耦。

 

異步：現場畫個圖來講明一下，A系統接收一個請求，須要在本身本地寫庫，還須要在BCD三個系統寫庫，本身本地寫庫要3ms，BCD三個系統分別寫庫要300ms、450ms、200ms。最終請求總延時是3 + 300 + 450 + 200 = 953ms，接近1s，用戶感受搞個什麼東西，慢死了慢死了。

 

削峯：天天0點到11點，A系統風平浪靜，每秒併發請求數量就100個。結果每次一到11點~1點，每秒併發請求數量忽然會暴增到1萬條。可是系統最大的處理能力就只能是每秒鐘處理1000個請求啊。。。尷尬了，系統會死。。。

 

（2）消息隊列有什麼優勢和缺點啊？

 

優勢上面已經說了，就是在特殊場景下有其對應的好處，解耦、異步、削峯

 

缺點呢？顯而易見的

 

系統可用性下降：系統引入的外部依賴越多，越容易掛掉，原本你就是A系統調用BCD三個系統的接口就行了，人ABCD四個系統好好的，沒啥問題，你偏加個MQ進來，萬一MQ掛了咋整？MQ掛了，整套系統崩潰了，你不就完了麼。

 

系統複雜性提升：硬生生加個MQ進來，你怎麼保證消息沒有重複消費？怎麼處理消息丟失的狀況？怎麼保證消息傳遞的順序性？頭大頭大，問題一大堆，痛苦不已

 

一致性問題：A系統處理完了直接返回成功了，人都覺得你這個請求就成功了；可是問題是，要是BCD三個系統那裏，BD兩個系統寫庫成功了，結果C系統寫庫失敗了，咋整？你這數據就不一致了。

 

因此消息隊列實際是一種很是複雜的架構，你引入它有不少好處，可是也得針對它帶來的壞處作各類額外的技術方案和架構來規避掉，最好以後，你會發現，媽呀，系統複雜度提高了一個數量級，也許是複雜了10倍。可是關鍵時刻，用，仍是得用的。。。

 

（3）kafka、activemq、rabbitmq、rocketmq都有什麼優勢和缺點啊？

 

常見的MQ其實就這幾種，別的還有不少其餘MQ，可是比較冷門的，那麼就別多說了

 

做爲一個碼農，你起碼得知道各類mq的優勢和缺點吧，我們來畫個表格看看

 

 

 

特性	ActiveMQ	RabbitMQ	RocketMQ	Kafka
單機吞吐量	萬級，吞吐量比RocketMQ和Kafka要低了一個數量級	萬級，吞吐量比RocketMQ和Kafka要低了一個數量級	10萬級，RocketMQ也是能夠支撐高吞吐的一種MQ	10萬級別，這是kafka最大的優勢，就是吞吐量高。   通常配合大數據類的系統來進行實時數據計算、日誌採集等場景
topic數量對吞吐量的影響			topic能夠達到幾百，幾千個的級別，吞吐量會有較小幅度的降低   這是RocketMQ的一大優點，在同等機器下，能夠支撐大量的topic	topic從幾十個到幾百個的時候，吞吐量會大幅度降低   因此在同等機器下，kafka儘可能保證topic數量不要過多。若是要支撐大規模topic，須要增長更多的機器資源
時效性	ms級	微秒級，這是rabbitmq的一大特色，延遲是最低的	ms級	延遲在ms級之內
可用性	高，基於主從架構實現高可用性	高，基於主從架構實現高可用性	很是高，分佈式架構	很是高，kafka是分佈式的，一個數據多個副本，少數機器宕機，不會丟失數據，不會致使不可用
消息可靠性	有較低的機率丟失數據		通過參數優化配置，能夠作到0丟失	通過參數優化配置，消息能夠作到0丟失
功能支持	MQ領域的功能極其完備	基於erlang開發，因此併發能力很強，性能極其好，延時很低	MQ功能較爲完善，仍是分佈式的，擴展性好	功能較爲簡單，主要支持簡單的MQ功能，在大數據領域的實時計算以及日誌採集被大規模使用，是事實上的標準
優劣勢總結	很是成熟，功能強大，在業內大量的公司以及項目中都有應用   偶爾會有較低機率丟失消息   並且如今社區以及國內應用都愈來愈少，官方社區如今對ActiveMQ 5.x維護愈來愈少，幾個月才發佈一個版本   並且確實主要是基於解耦和異步來用的，較少在大規模吞吐的場景中使用	erlang語言開發，性能極其好，延時很低；   吞吐量到萬級，MQ功能比較完備   並且開源提供的管理界面很是棒，用起來很好用   社區相對比較活躍，幾乎每月都發布幾個版本分   在國內一些互聯網公司近幾年用rabbitmq也比較多一些   可是問題也是顯而易見的，RabbitMQ確實吞吐量會低一些，這是由於他作的實現機制比較重。   並且erlang開發，國內有幾個公司有實力作erlang源碼級別的研究和定製？若是說你沒這個實力的話，確實偶爾會有一些問題，你很難去看懂源碼，你公司對這個東西的掌控很弱，基本職能依賴於開源社區的快速維護和修復bug。   並且rabbitmq集羣動態擴展會很麻煩，不過這個我以爲還好。其實主要是erlang語言自己帶來的問題。很難讀源碼，很難定製和掌控。	接口簡單易用，並且畢竟在阿里大規模應用過，有阿里品牌保障   日處理消息上百億之多，能夠作到大規模吞吐，性能也很是好，分佈式擴展也很方便，社區維護還能夠，可靠性和可用性都是ok的，還能夠支撐大規模的topic數量，支持複雜MQ業務場景   並且一個很大的優點在於，阿里出品都是java系的，咱們能夠本身閱讀源碼，定製本身公司的MQ，能夠掌控   社區活躍度相對較爲通常，不過也還能夠，文檔相對來講簡單一些，而後接口這塊不是按照標準JMS規範走的有些系統要遷移須要修改大量代碼   還有就是阿里出臺的技術，你得作好這個技術萬一被拋棄，社區黃掉的風險，那若是大家公司有技術實力我以爲用RocketMQ挺好的	kafka的特色其實很明顯，就是僅僅提供較少的核心功能，可是提供超高的吞吐量，ms級的延遲，極高的可用性以及可靠性，並且分佈式能夠任意擴展   同時kafka最好是支撐較少的topic數量便可，保證其超高吞吐量   並且kafka惟一的一點劣勢是有可能消息重複消費，那麼對數據準確性會形成極其輕微的影響，在大數據領域中以及日誌採集中，這點輕微影響能夠忽略   這個特性自然適合大數據實時計算以及日誌收集

 

 

綜上所述，各類對比以後，我我的傾向因而：

 

通常的業務系統要引入MQ，最先你們都用ActiveMQ，可是如今確實你們用的很少了，沒通過大規模吞吐量場景的驗證，社區也不是很活躍，因此你們仍是算了吧，我我的不推薦用這個了；

 

後來你們開始用RabbitMQ，可是確實erlang語言阻止了大量的java工程師去深刻研究和掌控他，對公司而言，幾乎處於不可控的狀態，可是確實人是開源的，比較穩定的支持，活躍度也高；

 

不過如今確實愈來愈多的公司，會去用RocketMQ，確實很不錯，可是我提醒一下本身想好社區萬一忽然黃掉的風險，對本身公司技術實力有絕對自信的，我推薦用RocketMQ，不然回去老老實實用RabbitMQ吧，人是活躍開源社區，絕對不會黃

 

因此中小型公司，技術實力較爲通常，技術挑戰不是特別高，用RabbitMQ是不錯的選擇；大型公司，基礎架構研發實力較強，用RocketMQ是很好的選擇

 

若是是大數據領域的實時計算、日誌採集等場景，用Kafka是業內標準的，絕對沒問題，社區活躍度很高，絕對不會黃，況且幾乎是全世界這個領域的事實性規範