首先,mq的作用有三個:
1.實現異步通信
同步通信是什麼樣的?發出一個調用請求之後,在沒有得到結果之前,就不返回,由調用者主動等待這個調用的結果,而異步是相反的,在調用發出之後,這個調用就直接返回了,所以沒有返回結果,也就是說,當一個異步過程調用發出後,調用者不會馬上得到結果,而是在調用發出後,被調用者通過狀態,通知來通知調用者,或者通過回調函數處理這個調用
2.實現系統解耦
在我們的分佈式系統中，一個業務流程涉及多個系統的時候，他們之間就會形成一個依賴關係。
比如我們以 12306 網站退票爲例，在傳統的通信方式中，訂單系統發生了退貨的動 作，那麼要依次調用所有下游系統的 API，比如調用庫存系統的 API 恢復庫存，因爲這張 火車票還要釋放出去給其他乘客購買；調用支付系統的 API，不論是支付寶微信還是銀行 卡，要把手續費扣掉以後，原路退回給消費者；調用通知系統 API 通知用戶退貨成功。
這個過程是串行執行的，如果在恢復庫存的時候發生了異常，那麼後面的代碼都不 會執行。由於這一系列的動作，恢復庫存，資金退還，發送通知，本質上沒有一個嚴格 的先後順序，也沒有直接的依賴關係，也就是說，只要用戶提交了退貨的請求，後面的這些動作都是要完成的。庫存有沒有恢復成功,不影響資金的退還和發送通知.
所以,這種情況下,我們可以引入MQ實現系統之間依賴關係
引入MQ之後:
訂單系統只需要把退貨的消息發送到消息隊列上，由各個下游的業務系統自己創建 隊列，然後監聽隊列消費消息。 在這種情況下訂單系統裏面就不需要配置其他系統的 IP、端口、接口地址了，因爲 它不需要關心消費者在網絡上的什麼位置，所以下游系統改 IP 沒有任何影響。甚至不需 要關心消費者有沒有消費成功，它只需要把消費發到消息隊列的服務器上就可以了。
這樣，我們就實現了系統之間依賴關係的解耦。
3.實現流量削峯
第三個主要功能,是實現流量削峯。 在很多的電商系統裏面，有一個瞬間流量達到峯值的情況，比如京東的 618，淘寶 的雙 11，還有小米搶購。普通的硬件服務器肯定支撐不了這種百萬或者千萬級別的併發 量，就像 2012 年的小米一樣，動不動服務器就崩潰。 如果通過堆硬件的方式去解決，那麼在流量峯值過去以後就會出現巨大的資源浪費。 那要怎麼辦呢？如果說要保護我們的應用服務器和數據庫，限流也是可以的，但是這樣 又會導致訂單的丟失，沒有達到我們的目的。 爲了解決這個問題，我們就可以引入 MQ，MQ 既然是隊列，一定有隊列的特性， 我們知道隊列的特性是什麼？ （先進先出 FIFO） 這樣，我們就可以先把所有的流量承接下來，轉換成 MQ 消息發送到消息隊列服務 器上，業務層就可以根據自己的消費速率去處理這些消息，處理之後再返回結果。就像 我們在火車站排隊一樣，大家只能一個一個買票，不會因爲人多就導致售票員忙不過來。 如果要處理快一點，大不了多開幾個窗口（增加幾個消費者）。
4.總結:
1)對於數量量大或者處理耗時長的操作,可以引入MQ實現異步通信,減少客戶端的等待,提升響應速度.
2)對於改動影響大的系統之間,可以引入MQ實現解耦,減少系統之間的直接依賴
3)對於出現瞬間的流量峯值的系統,可以引入MQ實現流量削峯,達到保護應用和數據庫的目的
5.使用消息隊列帶來的一些問題
1)系統可用性降低:原來是兩個節點的通信,現在還需要獨立運行一個服務,如果MQ服務器或者通信網絡出現問題,就會導致請求失敗
2)系統複雜性提高:第一開發者必須要理解相關的模型和概念,才能正確的配置和使用MQ,第二使用MQ發送消息必須要考慮消息丟失和消息重複消費的問題,一旦消息沒有被正確的消費,就會帶來數據一致性的問題