爲什麼要使用MQ
先說一下MQ常見的使用場景吧，MQ的使用場景有很多，但是比較核心的就是：解耦、異步、削鋒。
系統解耦
首先舉例下面這個場景，現有ABCDE五個系統，最初的時候BCD三個系統都要調用A系統的接口獲取數據，一切都很正常，但是突然，D系統說：我不要了，你不用給我傳數據了，A系統無奈，只能修改代碼，將調用D系統的代碼刪除，這時候還沒刪除呢，E系統發送了請求，但是A系統這時候還沒處理完D系統的請求，A系統卒！！！徹底崩潰。如下圖
上述場景中，BCDE都需要用到A系統提供的數據，A系統跟其他四個系統嚴重耦合，需要時時刻刻考慮其他四個系統要是掛了怎麼辦，需不需要重新發送數據給他們，這個時候的A系統內心是崩潰的。
但是如果使用了MQ之後 ，A系統的數據只需要放到MQ裏面，其他的系統想請求獲取數據只需要去MQ裏面消費即可，如果突然不想請求了，就取消對MQ的消費就行了，A系統根本不需要考慮給誰去響應這個數據，也不需要去維護代碼，也不用考慮其他系統是否調用成功，失敗超時等情況。如下圖
總結：通過MQ發佈訂閱消息的模型，A系統就成功的跟其他系統解耦了。
Tips：你需要思考一下，在你自己的系統裏面有沒有類似的情況，一個系統或者模塊，調用了多個系統或者模塊，它們互相之間的調用非常複雜，並且維護起來很麻煩，但其實這個調用是不需要直接同步調用接口的，如果用MQ給它異步化解耦也是可以的，你就需要思考在你的項目裏，是不是可以用MQ給它進行系統的解耦。
異步調用
場景二，還是ABCD四個系統，A系統收到一個請求，需要在自己本地寫庫，還需要往BCD三個系統寫庫，A系統自己寫本地庫需要3ms，往其他系統寫庫相對較慢，B系統200ms ，C系統350ms，D系統400ms，這樣算起來，整個功能從請求到響應的時間爲3ms+200ms+350ms+400ms=953ms，接近一秒，對於用戶來說，點個按鈕要等這麼長時間，基本是無法接受的，側面也反映出這家研發人員技術不咋地。如下圖
一般的互聯網企業，對於用戶請求響應的時間要求在100ms-200ms之間，這樣，用戶的眼睛存在視覺暫停現象，用戶響應時間在此範圍內就可以了，所以上面的現象是不可取的。
如果用了MQ，用戶發送請求到A系統耗時3ms，A系統發送三條消息到MQ，假如耗時5ms，用戶從發送請求到相應3ms+5ms=8ms，僅用了8ms，用戶的體驗非常好。
流量削峯
場景三，這次舉個實例吧，也是近期發生的，我們都知道 ，2020年爆發的這場新冠病毒，導致各大線上商城APP裏面的口罩被搶購一空，在這種情況下，JD商城開啓了一場每晚八點的搶購3Q口罩的活動，每天下午三點進行預約，晚上八點搶購，從JD商城剛上線這個活動，我連續搶了近一個周，也算是見證了一個百萬併發量系統從出現問題到完善的一個過程，最初第一天，我搶購的時候，一百多萬預約，到八點搶購估計也能有百萬的併發量，可是第一天，到八點我搶的時候，由於併發量太高，直接把JD服務器弄崩了，直接報了異常，可能JD在上線這個活動的時候也沒能夠想到會有那麼高的併發，打了一個猝不及防，但是這只是在前一兩天出現報異常的情況，後面卻沒有再出現異常信息，到後來再搶購只是響應的時間變得很慢，但是JD系統並沒有崩潰，這種情況下一般就是用了MQ（或者之前用了MQ，這次換了個吞吐量級別更高的MQ），也正是利用了MQ的三大好處之一——削峯。
JD系統每天0—19點，系統風平浪靜，結果一到八點搶購的時候，每秒併發達到百萬，假設JD數據庫沒秒能處理1.5w條併發請求（並非實際數據，主要爲了舉例）,到八點搶購的時候，每秒併發百萬，這直接導致系統異常，但是八點一過，可能也就幾萬用戶在線操作，每秒的請求可能也就幾百條，對整個系統毫無壓力。
如果使用了MQ，每秒百萬個請求寫入MQ，因爲JD系統每秒能處理1W+的請求，JD系統處理完然後再去MQ裏面，再拉取1W+的請求處理，每次不要超過自己能處理的最大請求量就ok，這樣下來，等到八點高峯期的時候，系統也不會掛掉，但是近一個小時內，系統處理請求的速度是肯定趕不上用戶的併發請求的，所以都會積壓在MQ中，甚至可能積壓千萬條，但是高峯期過後，每秒只會有一千多的併發請求進入MQ，但是JD系統還是會以每秒1W+的速度處理請求，所以高峯期一過，JD系統會很快消化掉積壓在MQ的請求，在用戶那邊可能也就是等的時間長一點，但是絕對不會讓系統掛掉。
消息隊列的優缺點
優點
系統解耦，異步調用，流量削峯。
缺點
①系統可用性降低： 系統引入的外部依賴越多，系統要面對的風險越高，拿場景一來說，本來ABCD四個系統配合的好好的，沒啥問題，但是你偏要弄個MQ進來插一腳，雖然好處挺多，但是萬一MQ掛掉了呢，那樣你係統不也就掛掉了。
②系統複雜程度提高： 非要加個MQ進來，如何保證沒有重複消費呢？如何處理消息丟失的情況？怎麼保證消息傳遞的順序？問題太多。
③一致性的問題： A系統處理完再傳遞給MQ就直接返回成功了，用戶以爲你這個請求成功了，但是，如果在BCD的系統裏，BC兩個系統寫庫成功，D系統寫庫失敗了怎麼辦，這樣就導致數據不一致了。
所以。消息隊列其實是一套非常複雜的架構，你在享受MQ帶來的好處的同時，也要做各種技術方案把MQ帶來的一系列的問題解決掉，等一切都做好之後，系統的複雜程度硬生生提高了一個等級。
四大主流MQ（kafka、ActiveMQ、RabbitMQ、RocketMQ）優缺點比對
綜上所述，各種對比之後，我個人傾向於是：
一般的業務系統要引入MQ，最早大家都用ActiveMQ，但是現在確實大家用的不多了，沒經過大規模吞吐量場景的驗證，社區也不是很活躍，所以大家還是算了吧，我個人不推薦用這個了；
後來大家開始用RabbitMQ，但是確實erlang語言阻止了大量的java工程師去深入研究和掌控他，對公司而言，幾乎處於不可控的狀態，但是確實人是開源的，比較穩定的支持，活躍度也高；
不過現在確實越來越多的公司，會去用RocketMQ，確實很不錯，但是我提醒一下自己想好社區萬一突然黃掉的風險，對自己公司技術實力有絕對自信的，我推薦用RocketMQ，否則回去老老實實用RabbitMQ吧，人是活躍開源社區，絕對不會黃。
所以中小型公司，技術實力較爲一般，技術挑戰不是特別高，用RabbitMQ是不錯的選擇；大型公司，基礎架構研發實力較強，用RocketMQ是很好的選擇
如果是大數據領域的實時計算、日誌採集等場景，用Kafka是業內標準的，絕對沒問題，社區活躍度很高，絕對不會黃，何況幾乎是全世界這個領域的事實性規範
原文參考公衆號【 】