目錄

一、概述? ?

? ? ? ?什么是消息中間件？

二、消息隊列的使用場景??

? ? ? ?為什么使用消息隊列？

? ? ? ?消息隊列有什么優缺點？

三、目前流行的消息隊列優缺點對比

四、總結??? ?

?

?

一、概述? ?

? ? ? ?什么是消息中間件？

消息隊列中間件（簡稱消息中間件）是指利用高效可靠的消息傳遞機制進行與平臺無關的數據交流，并基于數據通信來進行分布式系統的集成。通過提供消息傳遞和消息排隊模型，它可以在分布式環境下提供應用解耦、彈性伸縮、冗余存儲、流量削峰、異步通信、數據同步等等功能，其作為分布式系統架構中的一個重要組件，有著舉足輕重的地位。個人感覺比價場景應用核心的有三個：解耦、異步、削峰。

?

二、消息隊列的使用場景??

? ? ? ?為什么使用消息隊列？

其實這個話題也是面試官經常問詢的問題，問問你消息隊列都有哪些使用場景，然后你項目里具體是什么場景，說說你在這個場景里用消息隊列是什么

期望的一個回答是說，你們公司有個什么業務場景，這個業務場景有個什么技術挑戰，如果不用MQ可能會很麻煩，但是你現在用了MQ之后帶給了你很多的好處

現在你可以下想想你如何回答上述問題，想不起來？? 好吧我這里先介紹幾個常見使用場景，提醒下。。。

解耦：現場畫個圖來說明一下，

?

A系統發送個數據到BCD三個系統，接口調用發送，那如果E系統也要這個數據呢？那如果C系統現在不需要了呢？現在A系統又要發送第二種數據了呢？A系統負責人瀕臨崩潰中。。。再來點更加崩潰的事兒，A系統要時時刻刻考慮BCDE四個系統如果掛了咋辦？我要不要重發？我要不要把消息存起來？頭發都白了啊。。。

?

?

這是你需要去考慮一下你負責的系統中是否有類似的場景，就是一個系統或者一個模塊，調用了多個系統或者模塊，互相之間的調用很復雜，維護起來很麻煩。但是其實這個調用是不需要直接同步調用接口的，如果用MQ給他異步化解耦，也是可以的，你就需要去考慮在你的項目里（做過微服務項目的同學這里是不是考慮下? 消息總線 搭配Rabbitmq 做解耦 用于廣播配置文件的更改或者服務間的通訊？），是不是可以運用這個MQ去進行系統的解耦。在簡歷中體現出來這塊東西，用MQ作解耦。

異步：現場畫個圖來說明一下，

?

?

A系統接收一個請求，需要在自己本地寫庫，還需要在BCD三個系統寫庫，自己本地寫庫要3ms，BCD三個系統分別寫庫要300ms、450ms、200ms。最終請求總延時是3 + 300 + 450 + 200 = 953ms，接近1s，用戶感覺搞個什么東西，慢死了慢死了。

更改為 異步后當消息發送到消息隊列? 自行讓對應系統進行消費即可? 所以給用戶的體驗為20 + 5 = 25ms? ,快 好快！

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

?

?

?

?

?消息隊列有什么優缺點？

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

?

缺點呢？顯而易見的

?

?

?

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

?

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

?

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

?

所以消息隊列實際是一種非常復雜的架構，你引入它有很多好處，但是也得針對它帶來的壞處做各種額外的技術方案和架構來規避掉，最好之后，你會發現，媽呀，系統復雜度提升了一個數量級，也許是復雜了10倍。但是關鍵時刻，用，還是得用的。。。

目前流行的消息隊列優缺點對比

kafka、activemq、rabbitmq、rocketmq都有什么優點和缺點啊？

常見的MQ其實就這幾種，別的還有很多其他MQ，但是比較冷門的，那么就別多說了

作為一個碼農，你起碼得知道各種mq的優點和缺點吧，咱們來畫個表格看看

?

?

綜上所述，各種對比之后，總結如下：

一般的業務系統要引入MQ，最早大家都用ActiveMQ，但是現在確實大家用的不多了，沒經過大規模吞吐量場景的驗證，社區也不是很活躍，所以大家還是算了吧，我個人不推薦用這個了；

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

不過現在確實越來越多的公司，會去用RocketMQ，確實很不錯，但是我提醒一下自己想好社區萬一突然黃掉的風險，對自己公司技術實力有絕對自信的，我推薦用RocketMQ，否則回去老老實實用RabbitMQ吧，人是活躍開源社區，絕對不會黃

所以中小型公司，技術實力較為一般，技術挑戰不是特別高，用RabbitMQ是不錯的選擇（我們項目也正在使用這個^_^）；大型公司，基礎架構研發實力較強，用RocketMQ是很好的選擇

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

轉自：https://blog.csdn.net/java_zyq/article/details/80022391

轉載于:https://www.cnblogs.com/itplay/p/10642533.html

總結

以上是生活随笔為你收集整理的【选型】消息中间件选型的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。