為什麼使用MQ？

現給結論：解耦,異步,削峰

（1）解耦

A 系統發送資料到 BCD 三個系統，通過接口調用發送。如果 E 系統也要這個資料呢？那如果 C 系統現在不需要了呢？A 系統負責人幾乎崩潰......A 系統跟其它各種亂七八糟的系統嚴重耦合，A 系統 産生一條比較關鍵的資料，很多系統都需要 A 系統将這個資料發送過來。如果使用 MQ，A 系統産生一 條資料，發送到 MQ 裡面去，哪個系統需要資料自己去 MQ 裡面消費。如果新系統需要資料，直接從 MQ 裡消費即可；如果某個系統不需要這條資料了，就取消對 MQ 消息的消費即可。這樣下來，A 系統壓根兒不需要去考慮要給誰發送資料，不需要維護這個代碼，也不需要考慮人家是否調用成功、失敗逾時等情況。 就是一個系統或者一個子產品，調用了多個系統或者子產品，互相之間的調用很複雜，維護起來很麻煩。但是其實這個調用是不需要直接同步調用接口的，如果用 MQ 給它異步化解耦。

（2）異步

A 系統接收一個請求，需要在自己本地寫庫，還需要在 BCD 三個系統寫庫，自己本地寫庫 要 3ms，BCD 三個系統分别寫庫要 400ms、350ms、300ms。最終請求總延時是 3 + 100 + 250 + 300 = 1053ms，整個耗時超過1s，使用者感覺搞個什麼東西，慢得要命。使用者通過浏覽器發起請求。如果使用 MQ，那麼 A 系統連續發送 3 條消息到 MQ 隊列中，假如耗時 5ms，A 系統從接受一個請求到傳回響應 給使用者，總時長是 3 + 5 = 8ms。

（3）削峰

減少高峰時期對伺服器壓力。

當然，MQ有很多優點，但也不乏缺點優，主要缺點有以下幾個

（1）系統可用性降低，系統引入的外部依賴越多，越容易挂掉。萬一 MQ 挂了，MQ 一挂，整套系統崩潰，你不就完了？

（2）系統複雜度提高，硬生生加個 MQ 進來，你怎麼保證消息沒有重複消費？怎麼處理消息丢失的情況？怎麼保證消息傳遞的 順序性？問題一大堆。