實戰前言

RabbitMQ 作為目前應用相當廣泛的訊息中介軟體，在企業級應用、微服務應用中充當著重要的角色。特別是在一些典型的應用場景以及業務模組中具有重要的作用，比如業務服務模組解耦、非同步通訊、高併發限流、超時業務、資料延遲處理等。上一篇博文我分享了RabbitMQ在業務服務模組解耦，非同步通訊與搶單系統高併發情況下限流作用等，感興趣的童鞋可以前往閱讀：https://blog.csdn.net/u013871100/article/details/82982235

這篇博文將繼續上篇博文留下來的死信佇列的實戰業務場景分享！

RabbitMQ 實戰：死信佇列認識與場景實戰

死信佇列認識

死信佇列，又可以稱之為“延遲/延時佇列”，也是佇列的一種，只不過與普通的佇列最大的不同之處在於建立時的組成成分不同，建立死信佇列的“成分”將不僅僅只是：名稱、持久化、自動刪除等基本屬性，還包含了死信交換機、死信路由甚至還有TTL（Time-To-Live）即佇列中訊息可生存的時間。

死信佇列其實最大的作用是可以實現訊息或者資料延遲/延時處理，而且還可以動態的設定延遲的時間，即動態設定 TTL。典型的業務場景很多，在這裡就不一一列舉了，總之，凡是業務中需要延遲一定時間再處理的資料均可以將其壓入死信佇列中，等待一定的時間後再執行真正的處理邏輯！

下面是死信佇列在建立、繫結、生產訊息、消費訊息過程的結構流程圖，在這裡其實已經很明確的指出死信佇列的建立跟繫結邏輯 以及 真正監聽消費處理訊息的佇列的繫結邏輯。圖中問題的答案為：當入死信佇列的訊息TTL一到，它自然而然的將被路由到  死信交換機繫結的佇列 中被真正消費處理！！！

死信佇列場景實戰

有了上面的流程圖做指導，接下來，我們將用死信佇列實戰這樣的一個業務場景：使用者在商城下單成功並點選去支付後在指定時間未支付時自動失效！

於是乎，我們需要建立兩個訊息模型，在 RabbitmqConfig 實施：

1. 死信佇列：用於設定指定的待支付的交易訂單號在指定的 TTL（單位為 ms）後何去何從！
2. 真正佇列：用於監聽消費處理指定的交易訂單號，即判斷該交易訂單號是否已完成，如果否，則失效之！

接下來是我們的生產端的邏輯：使用者商城下單的處理！

接下來是等待固定的 TTL：在這裡設定的是 10s，當訊息入死信佇列 10s 後，將自然而然的將訊息路由到下一個中轉站，即真正的消費監聽處理佇列進行處理：判斷該筆交易訂單號是否已經付款，如果否，則失效之！

可以將該服務跑起來，然後發起 controller 的使用者下單請求，會發現訊息入死信佇列後不會立馬被消費，等待 10s 會，訊息會被路由到真正的消費佇列中進行處理，這一現象可以在 MQ 的後端控制檯應用中看到！

總結：到此我們的死信佇列已經實戰完畢，回顧我們所介紹的歷程，其實核心重點在於上面的那張 “死信佇列的結構流程圖”，理解了這個結構流程圖中的相關元件及其流程，則在實戰各種需要延時處理的業務場景將得心應手，包括如何建立死信佇列，如何面向生產端繫結死信佇列，如何面向消費端繫結真正的佇列等等！而對於死信佇列的實戰場景，前面也介紹過了：凡是需要等待一定時間或者需要緩一緩特定時間的業務、資料均可以通過死信佇列來實現！

回顧與總結

RabbitMQ 的認識與實際業務場景的實戰到此我都已經介紹完畢，總體而言，RabbitMQ 作為目前應用相當廣泛的訊息中介軟體，在我們實際系統的業務模組中具有重要的作用，特別是剛開始介紹的幾種訊息模型以及死信佇列模型在微服務系統、分散式系統中均可充當重要的角色，其中我們實戰的業務場景包括業務服務模組解耦非同步通訊（非同步傳送日誌、非同步傳送郵件）；另外，我們還介紹了訊息確認機制，這是一種 MQ 確保訊息能被消費者消費的機制，對於一些業務模組也是有廣泛的應用；除此之外，我們還模擬實戰了秒殺系統、搶單系統這樣的業務場景下 RabbitMQ 的作用：限流、排隊緩壓、減少資料庫讀寫鎖的發生等等！

彩蛋：本博文介紹了RabbitMQ死信佇列及其業務場景的實戰，相關原始碼資料庫可以來這裡下載

（1）https://download.csdn.net/download/u013871100/10654482

（2）https://pan.baidu.com/s/1KUuz_eeFXOKF3XRMY2Jcew
學習過程有任何問題均可以與我交流，QQ：1974544863！感興趣的童鞋可以關注一下我的微信公眾號！