1.為什么使用消息隊列啊？
通用回答是：我們公司有個什么業務場景，這個業務場景有個什么技術挑戰，如果不用MQ可能會很麻煩，但是你現在用了MQ之后帶給了你很多的好處。
比較核心的有3個業務場景：解耦、異步、削峰
解耦：現場畫個圖來說明一下，A系統發送個數據到BCD三個系統，接口調用發送，那如果E系統也要這個數據呢？那如果C系統現在不需要了呢？現在A系統又要發送第二種數據了呢？A系統負責人瀕臨崩潰中。。。再來點更加崩潰的事兒，A系統要時時刻刻考慮BCDE四個系統如果掛了咋辦？我要不要重發？我要不要把消息存起來？頭發都白了啊。。。
不用MQ的系統耦合場景：
使用了MQ之后的解耦場景：
異步：現場畫個圖來說明一下，A系統接收一個請求，需要在自己本地寫庫，還需要在BCD三個系統寫庫，自己本地寫庫要3ms，BCD三個系統分別寫庫要300ms、450ms、200ms。最終請求總延時是3 + 300 + 450 + 200 = 953ms，接近1s，用戶感覺搞個什么東西，慢死了慢死了。
不用MQ的同步高延時請求場景：
使用了MQ進行異步之后的接口性能優化：
削峰：每天0點到11點，A系統風平浪靜，每秒並發請求數量就100個。結果每次一到11點~1點，每秒並發請求數量突然會暴增到1萬條。但是系統最大的處理能力就只能是每秒鍾處理1000個請求啊。。。尷尬了，系統會死。。。
沒用MQ高峰期系統被打死的場景：
使用MQ來進行削峰的場景：
（2）消息隊列有什么優點和缺點啊？
優點上面已經說了，就是在特殊場景下有其對應的好處，解耦、異步、削峰
缺點呢？顯而易見的
系統可用性降低：系統引入的外部依賴越多，越容易掛掉，本來你就是A系統調用BCD三個系統的接口就好了，人ABCD四個系統好好的，沒啥問題，你偏加個MQ進來，萬一MQ掛了咋整？MQ掛了，整套系統崩潰了，你不就完了么。
系統復雜性提高：硬生生加個MQ進來，你怎么保證消息沒有重復消費？怎么處理消息丟失的情況？怎么保證消息傳遞的順序性？頭大頭大，問題一大堆，痛苦不已
一致性問題：A系統處理完了直接返回成功了，人都以為你這個請求就成功了；但是問題是，要是BCD三個系統那里，BD兩個系統寫庫成功了，結果C系統寫庫失敗了，咋整？你這數據就不一致了。
所以消息隊列實際是一種非常復雜的架構，你引入它有很多好處，但是也得針對它帶來的壞處做各種額外的技術方案和架構來規避掉，最好之后，你會發現，媽呀，系統復雜度提升了一個數量級，也許是復雜了10倍。但是關鍵時刻，用，還是得用的。。。
