SpringBoot整合RabbitMQ之典型應用場景實戰三

實戰前言
RabbitMQ 做爲目前應用至關普遍的消息中間件，在企業級應用、微服務應用中充當着重要的角色。特別是在一些典型的應用場景以及業務模塊中具備重要的做用，好比業務服務模塊解耦、異步通訊、高併發限流、超時業務、數據延遲處理等。前兩篇博文我介紹分享了RabbitMQ在業務服務模塊異步解耦以及通訊的實戰業務場景，感興趣童鞋能夠前往觀看：
1.http://www.javashuo.com/article/p-rnbmlolo-do.html
2.http://www.javashuo.com/article/p-spfvphyl-dc.html

這篇博文咱們繼續介紹分享RabbitMQ死信隊列實戰以及在支付系統中支付過程超時則自動失效其下單記錄 這樣的業務場景！

該課程的學習鏈接：http://edu.51cto.com/course/14858.html

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

死信隊列認識

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

死信隊列其實最大的做用是能夠實現消息或者數據延遲/延時處理，並且還能夠動態的設定延遲的時間，即動態設定 TTL。典型的業務場景不少，在這裏就不一一列舉了，總之，凡是業務中須要延遲必定時間再處理的數據都可以將其壓入死信隊列中，等待必定的時間後再執行真正的處理邏輯！

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

死信隊列場景實戰

有了上面的流程圖作指導，接下來，咱們將用死信隊列實戰這樣的一個業務場景：用戶在商城下單成功並點擊去支付後在指定時間未支付時自動失效！因而乎，咱們須要建立兩個消息模型，在 RabbitmqConfig 實施：

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

接下來是咱們的生產端的邏輯：用戶商城下單的處理！

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

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

總結：到此咱們的死信隊列已經實戰完畢，回顧咱們所介紹的歷程，其實核心重點在於上面的那張 「死信隊列的結構流程圖」，理解了這個結構流程圖中的相關組件及其流程，則在實戰各類須要延時處理的業務場景將駕輕就熟，包括如何建立死信隊列，如何面向生產端綁定死信隊列，如何面向消費端綁定真正的隊列等等！而對於死信隊列的實戰場景，前面也介紹過了：凡是須要等待必定時間或者須要緩一緩特定時間的業務、數據都可以經過死信隊列來實現！

回顧與總結

RabbitMQ 的認識與實際業務場景的實戰到此我都已經介紹完畢，整體而言，RabbitMQ 做爲目前應用至關普遍的消息中間件，在咱們實際系統的業務模塊中具備重要的做用，特別是剛開始介紹的幾種消息模型以及死信隊列模型在微服務系統、分佈式系統中都可充當重要的角色，其中咱們實戰的業務場景包括業務服務模塊解耦異步通訊（異步發送日誌、異步發送郵件）；另外，咱們還介紹了消息確認機制，這是一種 MQ 確保消息能被消費者消費的機制，對於一些業務模塊也是有普遍的應用；除此以外，咱們還模擬實戰了秒殺系統、搶單系統這樣的業務場景下 RabbitMQ 的做用：限流、排隊緩壓、減小數據庫讀寫鎖的發生等等！

彩蛋：本博文介紹了RabbitMQ死信隊列及其業務場景的實戰，相關源碼數據庫能夠來這裏下載！

地址：https://pan.baidu.com/s/1KUuz_eeFXOKF3XRMY2Jcew
學習過程有任何問題都可以與我交流，QQ：1974544863！感興趣的童鞋能夠關注一下個人微信公衆號！

附註：debug已經將RabbitMQ的實戰整理成了視頻教程，感興趣的童鞋能夠加上面公衆號或者我的QQ交流！