假設乙個訂單在整個交易系統會經歷如下兩個步驟：
a:訂單建立
b:訂單出庫
整個過程，如下圖所示：
但是現在有了新需求，我們需要在統計訂單的建立資料，便於在雙11的時候用於分析實時系統下單總銷量，就像天貓雙11大螢幕那樣展示當前時刻的單量和銷售額。你想到了乙個方案對建立訂單的介面進行了一系列的更改，改完後有來了乙個新功能，現在我們不僅要統計總銷量，還要統計每個省份的銷量，於是乎你又不得不去更改下單介面。而下單介面對整個系統來說又是非常重要的乙個介面，一旦更改勢必影響甚廣。顯然這種方法是不可取的。
而現在你可以嘗試使用訊息中介軟體來對系統進行解耦操作了。訂單的實時銷售資料統計從建立之中分離出來，採用訊息非同步進行處理，既能不影響訂單的建立，通過及時的訊息消費與流式框架處理，使之接近實時的銷售資料展示。
再則又有新的功能。公司能夠支撐多承運商發貨了，我們不用更改訂單的發貨功能，而是與訂單建立類似的實現方式利用訊息進行系統解耦
通過引入訊息中介軟體後對原系統的架構無任何影響，無需更改之前的任何**。同時通過佇列的方式還可以對訊息進行並行處理，通過主題模對同乙個訊息進行不同的處理。
我們再回到訂單建立使用訊息中介軟體之前，訂單建立介面假如有如下步驟：
整個訂單建立介面總耗時 100 + 500 + 300 ，發現訂單落庫只需要1/9的時間，其它大部分時間用在了傳送簡訊和增加積分上面。但是這兩個步驟對於整個訂單的建立來說是非必須的，且並不是一定要求下單後立刻給使用者傳送簡訊和增加使用者積分。
通過訊息中介軟體進行非同步呼叫後：
訂單建立介面現在只需要100ms+傳送訊息耗時，同時傳送簡訊和增加積分是非同步進行處理的不影響下單的介面效能，極大的提高了使用者下單功能的體驗。
假設你有乙個系統，平時正常的時候每秒可能就幾百個請求，但是在雙11的時候，每秒鐘幾千上萬的請求，瞬時出現了流量高峰，此時你的選擇是要搞10臺機器，抗住每秒成千上萬請求的瞬時高峰嗎？而且僅僅為了雙11的那幾天，如果你線上部署了很多臺機器，那麼每台機器就處理每秒幾十個請求就可以了，這不是有點浪費機器資源嗎？
此時我們就可以用mq中介軟體來進行流量削峰。所有機器前面部署一層mq，平時每秒幾百請求大家都可以輕鬆接收訊息。
一旦到了瞬時高峰期，一下湧入每秒幾千的請求，就可以積壓在mq裡面，然後那一台機器慢慢的處理和消費。
等高峰期過了，再消費一段時間，mq裡積壓的資料就消費完畢了。
ps:以上部分內容**於網路
為什麼要使用MQ訊息中介軟體？
在面試大型網際網路公司的時候，很可能會被問到訊息佇列的問題 1.在何種場景下使用了訊息中介軟體？2.為什麼要在系統裡引入訊息中介軟體？3.如何實現冪等？鏈式呼叫是我們在寫程式時候的一般流程，為了完成乙個整體功能，會將其拆分成多個函式 或子模組 比如模組a呼叫模組b，模組b呼叫模組c，模組c呼叫模組d...
為什麼要使用MQ訊息中介軟體？它解決了什麼問題？
場景說明 使用者註冊後，需要發註冊郵件和註冊簡訊,傳統的做法有兩種1.序列的方式 2.並行的方式 1 序列方式 將註冊資訊寫入資料庫後,傳送註冊郵件,再傳送註冊簡訊,以上三個任務全部完成後才返回給客戶端。這有乙個問題是,郵件,簡訊並不是必須的,它只是乙個通知,而這種做法讓客戶端等待沒有必要等待的東西...
訊息中介軟體
1.訊息的優先順序 2.訊息排序 3.訊息過濾 4.訊息持久化 5.訊息重試 6.事務的支援 7.broker滿 生產者，佇列，消費者 訊息佇列的優點 1 解耦2 非同步訊息，系統響應 在jms中，有兩種訊息模型 點對點模式和發布訂閱模式。1.在點對點模式中 有三種角色 1 訊息佇列，傳送者，接受者...