1.消息隊列的優點
1）解耦
場景：當A系統需要發送數據到BCD三個系統時。
如果使用接口調用，A系統是和BCD系統耦合在一起的，需要考慮BCD系統掛了怎么辦？BCD系統消費失敗怎么辦？如果E系統也需要這個數據？如果B系統現在不需要這個數據？
如果使用MQ，A系統產生的數據，只要保證消息成功發送到MQ中。各個系統需要數據，自己到MQ中消費。如果新系統需要數據，直接從MQ里消費，如果老系統不需要數據了，直接取消對MQ的消費。
通過MQ，A系統和其他系統徹底解耦了。
2）異步
場景：A系統接到請求，需要在本系統寫庫，還需要在BCD三個系統寫庫。
自己本地寫庫要 3ms，BCD 三個系統分別寫庫要 300ms、450ms、200ms。如果同步調用，最終請求總延時是 3 + 300 + 450 + 200 = 953ms。
如果使用MQ，A系統發送三個消息到三個MQ，假設耗時5ms，則A 系統從接受一個請求到返回響應給用戶，總時長是 3 + 5 = 8ms。
3）消峰
場景：每天 0:00 到 12:00，A 系統風平浪靜，每秒並發請求數量就 50 個。結果每次一到 12:00 ~ 13:00 ，每秒並發請求數量突然會暴增到 5k+ 條。但是系統是直接基於 MySQL 的，大量的請求涌入 MySQL，每秒鍾對 MySQL 執行約 5k 條 SQL。
一般的 MySQL，扛到每秒 2k 個請求就差不多了，如果每秒請求到 5k 的話，可能就直接把 MySQL 給打死了，導致系統崩潰，用戶也就沒法再使用系統了。
如果使用 MQ，每秒 5k 個請求寫入 MQ，A 系統每秒鍾最多處理 2k 個請求，因為 MySQL 每秒鍾最多處理 2k 個。A 系統從 MQ 中慢慢拉取請求，每秒鍾就拉取 2k 個請求，不要超過自己每秒能處理的最大請求數量就 ok，這樣下來，哪怕是高峰期的時候，A 系統也絕對不會掛掉。
2.消息隊列的缺點
1）系統可用性降低
外部依賴的系統多了，增加了消息隊列系統。
2）系統復雜度提高
你怎么保證消息沒有重復消費？怎么處理消息丟失的情況？怎么保證消息傳遞的順序性？
3）一致性問題
數據可能不一致。