爲什麼要使用消息中間件？
1. 系統解耦
假設一個訂單在整個交易系統會經歷如下兩個步驟：
A:訂單創建
B:訂單出庫
整個過程，如下圖所示：
但是現在有了新需求，我們需要在統計訂單的創建數據，便於在雙11的時候用於分析實時系統下單總銷量，就像天貓雙11大屏幕那樣展示當前時刻的單量和銷售額。你想到了一個方案對創建訂單的接口進行了一系列的更改，改完後有來了一個新功能，現在我們不僅要統計總銷量，還要統計每個省份的銷量，於是乎你又不得不去更改下單接口。而下單接口對整個系統來說又是非常重要的一個接口，一旦更改勢必影響甚廣。顯然這種方法是不可取的。
而現在你可以嘗試使用消息中間件來對系統進行解耦操作了。訂單的實時銷售數據統計從創建之中分離出來，採用消息異步進行處理，既能不影響訂單的創建，通過及時的消息消費與流式框架處理，使之接近實時的銷售數據展示。
再則又有新的功能。公司能夠支撐多承運商發貨了，我們不用更改訂單的發貨功能，而是與訂單創建類似的實現方式利用消息進行系統解耦
通過引入消息中間件後對原系統的架構無任何影響，無需更改之前的任何代碼。同時通過隊列的方式還可以對消息進行並行處理，通過主題模對同一個消息進行不同的處理。
2. 異步調用
我們再回到訂單創建使用消息中間件之前，訂單創建接口假如有如下步驟：
整個訂單創建接口總耗時 100 + 500 + 300 ，發現訂單落庫只需要1/9的時間，其它大部分時間用在了發送短信和增加積分上面。但是這兩個步驟對於整個訂單的創建來說是非必須的，且並不是一定要求下單後立刻給用戶發送短信和增加用戶積分。
通過消息中間件進行異步調用後：
訂單創建接口現在只需要100ms+發送消息耗時，同時發送短信和增加積分是異步進行處理的不影響下單的接口性能，極大的提高了用戶下單功能的體驗。
3. 流量削峯
假設你有一個系統，平時正常的時候每秒可能就幾百個請求，但是在雙11的時候，每秒鐘幾千上萬的請求，瞬時出現了流量高峯，此時你的選擇是要搞10臺機器，抗住每秒成千上萬請求的瞬時高峯嗎？而且僅僅爲了雙11的那幾天，如果你線上部署了很多臺機器，那麼每臺機器就處理每秒幾十個請求就可以了，這不是有點浪費機器資源嗎？
此時我們就可以用MQ中間件來進行流量削峯。所有機器前面部署一層MQ，平時每秒幾百請求大家都可以輕鬆接收消息。
一旦到了瞬時高峯期，一下涌入每秒幾千的請求，就可以積壓在MQ裏面，然後那一臺機器慢慢的處理和消費。
等高峯期過了，再消費一段時間，MQ裏積壓的數據就消費完畢了。
ps:以上部分內容來源於網絡