在剛入MQ這個坑的時候，確實會覺得MQ真的不錯，既可以解決多個系統耦合度太高的問題，又可以解決系統同步請求耗時的問題，還能大大降低請求資源對於系統以及數據庫的壓力，也就是我們常說的MQ的三大好處：
1、解耦：
就是一個系統或者一個模塊，調用了多個系統或者模塊，互相之間的調用很復雜，維護起來很麻煩。其實這個調用是不需要直接同步調用接口的，皆可以用MQ給他異步化解耦。
2、異步：
一個系統接收一個請求，需要在本地寫庫，還需要在另外幾個相關的系統寫庫都需要一定的時長。最終請求總延時是就是三者的總時長，而當使用MQ異步請求，也就是兩個時長，第一個是創建MQ，第二個是將消息放入MQ中，這樣會大大提高效率。
3、削峰
可能每個系統的早高峰不一樣，有些系統是上班期間訪問量很大，有些系統是下班時間訪問量大，所以，我們需要用MQ來降低並發請求到數據庫的數據，給數據庫一定的時間去處理，不然一起擁進到數據庫，系統就會崩了。
當然，使用這個MQ還會有好些個坑。
1）、系統可用性降低：系統引入的外部依賴越多，越容易掛掉，可能開始，你就是一個系統調用幾個系統的接口，被調用的系統好好的，沒啥問題，如果加個了MQ進來，MQ可能會掛掉，一旦MQ掛了，整套系統崩潰了，就會出大問題。
2）、系統復雜性提高：強行使用MQ，消息可能會重復消費，消息也有可能會丟失，消息傳遞的順序性也可能會亂序，問題一大堆。
3）、一致性問題：一個系統處理完了直接返回成功了，就會以為這請求處理是成功的；但是實際上是，另外的系統那里，可能某幾個系統寫庫成功了，結果有個系統寫庫失敗了，容易導致數據不一致。
所以消息隊列實際是一種非常復雜的架構，你引入對系統可能提速不少，但是也得針對它做各種技術方案和架構來避開他的弊端，可能用完了之后，你會發現這個系統復雜度也提高了很多，如果有需要，才加入MQ。