一、為什要使用MQ
-
（解耦）實作分布式系統之間的解耦調用
業務中有這樣的一個場景：
有系統A（訂單），系統B（短信），系統C（優惠卷），系統D（庫存）
-
商品訂單确認，後續需要給客戶發送短信，需要扣除優惠卷，需要扣減庫存，假設後續需要加一個其他的系統，就需要修改A系統中的代碼，删除一個同理，這樣非常的麻煩
在這個場景中，A 系統跟其它各種亂七八糟的系統嚴重耦合，A 系統産生一條比較關鍵的資料，很多系統都需要 A 系統将這個資料發送過來。A 系統要時時刻刻考慮 BCD 四個系統如果挂了該咋辦？要不要重發，要不要把消息存起來？頭發都白了啊！
如果可以把系統A所要發送的消息放在一個地方，誰需要誰去拿，比如圖書管理者----書架----借閱者
如果使用 MQ，A 系統産生一條資料，發送到 MQ 裡面去，哪個系統需要資料自己去 MQ 裡面消費。如果新系統需要資料，直接從 MQ 裡消費即可；如果某個系統不需要這條資料了，就取消對 MQ 消息的消費即可。這樣下來，A 系統壓根兒不需要去考慮要給誰發送資料，不需要維護這個代碼，也不需要考慮人家是否調用成功、失敗逾時等情況。
使用場景：
一個系統或者一個子產品，調用了多個系統或者子產品，互相之間的調用很複雜，維護起來很麻煩
- （異步）實作異步調用
系統A産生一個消息，然後經過系統B，系統C，系統D，假設每個系統都需要100s，合起來就是400s…
這樣非常的消耗時間，使用MQ
這樣的話系統A建立消息100S—>發送到MQ100S 200S解決
- （削峰）削峰（隊列），解決高并發問題
最好的例子就是：秒殺，秒殺活動，一般會因為流量過大，導緻應用挂掉。
10000ops直接請求到資料庫，資料庫連接配接異常 GG
加入MQ進行流量削峰
使用 MQ，每秒 1k 個請求寫入 MQ，BCD系統每秒鐘最多處理 100 個請求，假設 MySQL 每秒鐘最多處理 100 個。BCD系統從 MQ 中慢慢拉取請求，每秒鐘就拉取 100 個請求，不要超過自己每秒能處理的最大請求數量就 ok，這樣下來，哪怕是高峰期的時候，BCD系統也絕對不會挂掉。而 MQ 每秒鐘 1k 個請求進來，就 100 個請求出去，結果就導緻在中午高峰期（1 個小時），可能有幾十萬甚至幾百萬的請求積壓在 MQ 中。
這個短暫的高峰期積壓是 ok 的，因為高峰期過了之後，每秒鐘就 50 個請求進 MQ，但是BCD系統依然會按照每秒 100 個請求的速度在處理。是以說，隻要高峰期一過，BCD系統就會快速将積壓的消息給解決掉。
中間件模式的的優點：
系統A慢慢的按照資料庫能處理的并發量，從消息隊列中慢慢拉取消息。在生産中，這個短暫的高峰期積壓是允許的。
二、使用會有什麼缺點？
-
系統可用性降低
系統引入的外部依賴越多，越容易挂掉。本來你就是 A 系統調用 BCD 三個系統的接口就好了，ABCD 四個系統還好好的，沒啥問題，你偏加個 MQ 進來，萬一 MQ 挂了咋整？MQ 一挂，整套系統崩潰，你不就完了
-
系統複雜度提高
硬生生加個 MQ 進來，你怎麼保證消息沒有重複消費？怎麼處理消息丢失的情況？怎麼保證消息傳遞的順序性？頭大頭大，問題一大堆，痛苦不已
-
一緻性問題
A 系統處理完了直接傳回成功了，人都以為你這個請求就成功了；但是問題是，要是 BCD 三個系統那裡，BD 兩個系統寫庫成功了，結果 C 系統寫庫失敗了，咋整？你這資料就不一緻了