在不使用訊息佇列伺服器的時候，使用者的請求資料直接寫入資料庫，在高併發的情況下資料庫壓力劇增，使得響應速度變慢。
但是在使用訊息佇列之後，使用者的請求資料傳送給訊息佇列之後立即返回，再由訊息佇列的消費者程序從訊息佇列中獲取資料，非同步寫入資料庫。由於訊息佇列伺服器處理速度快於資料庫（訊息佇列也比資料庫有更好的伸縮性），因此響應速度得到大幅改善。
下面舉個栗子：
在沒有使用訊息佇列的時候：
此時：1.使用者對系統a發起了請求；
2.這個請求需要系統a去依次呼叫系統b、系統c和系統d；
3.那麼這個請求要返還給使用者，需要花費20+300+450+200=970ms；
如果使用了訊息佇列：
1.使用者對系統a發起了請求；
2.系統a連續傳送3條訊息到3個mq之中去；
3.系統a返回使用者請求，同時系統b、系統c、系統d從各自的訊息佇列去拿程序進行消費。
那麼這個系統返回的使用者的時間為：20+5=25ms.
但是非同步需要注意的是：
使用者請求資料寫入訊息佇列之後就立即返回給使用者了，但是請求資料在後續的業務校驗、寫資料庫等操作中可能失敗。因此使用訊息佇列進行非同步處理之後，需要適當修改業務流程進行配合，比如使用者在提交訂單之後，訂單資料寫入訊息佇列，不能立即返回使用者訂單提交成功，需要在訊息佇列的訂單消費者進**正處理完該訂單之後，甚至出庫後，再通過電子郵件或簡訊通知使用者訂單成功，以免交易糾紛。這就類似我們平時手機訂火車票和電影票。
如果模組之間不存在直接呼叫，那麼新增模組或者修改模組就對其他模組影響較小，這樣系統的可擴充套件性無疑更好一些。
常見的事件驅動架構類似生產者消費者模式，在大型**中通常用利用訊息佇列實現事件驅動結構。
如下圖所示：
發布-訂閱模式工作，訊息傳送者（生產者）發布訊息，乙個或多個訊息接受者（消費者）訂閱訊息。
從上圖可以看到訊息傳送者（生產者）和訊息接受者（消費者）之間沒有直接耦合，訊息傳送者將訊息傳送至分布式訊息佇列即結束對訊息的處理，訊息接受者從分布式訊息佇列獲取該訊息後進行後續處理，並不需要知道該訊息從何而來。
對新增業務，只要對該類訊息感興趣，即可訂閱該訊息，對原有系統和業務沒有任何影響，從而實現**業務的可擴充套件性設計。
另外為了避免訊息佇列伺服器宕機造成訊息丟失，會將成功傳送到訊息佇列的訊息儲存在訊息生產者伺服器上，等訊息真正被消費者伺服器處理後才刪除訊息。在訊息佇列伺服器宕機後，生產者伺服器會選擇分布式訊息佇列伺服器集群中的其他伺服器發布訊息。
在沒有使用訊息佇列的時候：
使用了訊息佇列之後：
發布-訂閱模式工作，只不過在解耦這個特定業務環境下是使用發布-訂閱模式的。除了發布-訂閱模式，還有點對點訂閱模式（乙個訊息只有乙個消費者），我們比較常用的是發布-訂閱模式。 另外，這兩種訊息模型是 jms 提供的，amqp 協議還提供了 5 種訊息模型。
在不使用訊息佇列的時候：
使用了訊息佇列之後：
參考：1.
2.中華石杉老師課程！
訊息佇列（一）
訊息佇列與pipe類似，但是存在兩個區別 message boundaries are preserved,so that readers and writes communicate in units of messages,rather than via an undelimited byte ...
一 訊息佇列
訊息佇列 message queue，簡稱為mq 是一種應用間的通訊方式，訊息傳送後可以立即返回，由訊息系統來確保訊息的可靠傳遞。訊息發布者只管把訊息發布到 mq 中而不用管誰來取，訊息使用者只管從 mq 中取訊息而不管是誰發布的。這樣發布者和使用者都不用知道對方的存在。訊息佇列中介軟體是分布式系統...
訊息佇列 訊息佇列
輪詢排程 一次性分發所有訊息，保證訊息平均分配，不管消費者是否能正常消費 訊息應答 保證消費端能確實消費，不丟失 公平 乙個乙個分發所有訊息,在保證分發到的執行緒確認回覆後，才分發下個訊息給下個空閒的消費者，訊息持久化 保證佇列中的訊息不丟失，包括3要素 交換器 訊息佇列 訊息都必須宣告持久化 發布...