概念：

訊息超時

這個很簡單，佇列中的訊息，不設定超時時間並且消費者宕機，就會越放越多，所以我們可以在建立queue的時候設定一個佇列大小和佇列超時時間。

死信交換機和死信佇列：

專門收集一些拒絕接受的，超時未消費的，超出了佇列大小的訊息任務。

使用場景：

（1）10件商品，100個使用者進來購買，佇列中大小設定為10，只允許10使用者購買請求進來，其他的都reject，reject的這部分都會自動進行死信佇列中，這也可以換成超出佇列大小的情況。
（2）10件商品，100個使用者進來購買，全部購買請求都放過期時間為10分鐘的佇列中，付款完成後算消費成功，10分鐘不付款的訂單記錄自動消失。超時消失的這部分訊息自動進入到死信佇列中記錄。

當然還有更多更復雜的，就靠自己DIY～
當然直接入庫或者通過redis也可以做，都可以，我當時設計搶購的模組是這樣選擇的：
通過MQ設定佇列大小限制搶購數量和儲存購買的使用者請求，這樣既可以保證有序，又可以保證超買超賣，Redis儲存預扣商品庫存的數量，支付時通過MQ的使用者購買請求和Redis中的預扣庫存生成訂單，調起支付的API和JS，完成支付後，扣除商品實際庫存數量和消費掉MQ中該使用者的購買請求。如果他一直沒能支付成功，MQ中的購買請求超時失效，訂單會保留，但是修改狀態為支付超時即可。
同時，如果MQ佔滿情況下，沒有死信佇列，會直接丟棄購買資訊。有了死信佇列，可以在前面有使用者支付超時或者退款的情況下移除該使用者出MQ，此時購買MQ的大小變為未滿，這時批量提醒死信佇列中的使用者，告訴他們現在“有機會”，讓他們進行二輪搶購。

這就是我的使用場景和解決方案，有的大神說：這麼麻煩幹嘛？我直接一個滑鏟，哦不，一個數據庫的增刪改查也可以。當然也可以，怎麼選擇是自己的事情。

整體流程

demo：

（1）先建立一個正常業務的交換機：

（2）在建立一個專門用於接受和轉發死信規則的死信交換機

要建立時候Argument引數加上x-dead-letter-exchange = 自己定義的死信交換機名稱即可
（3）建立一個dead.letter作為正常業務佇列，設定過期時間和設定最大限制，這樣才能讓訊息在這個正常業務佇列過期。這個正常業務的可以不加x-dead-letter-exchange也行

建立成功！

（4）建立一個dlx.queue作為全域性死信佇列，跟剛才建立做法一樣，不需要過期時間和最大限制也行，反正它就是一個垃圾桶的作用

（5）將正常業務佇列與正常業務交換機和死信交換機都要繫結！

（6）死信佇列只需要繫結死信交換機

（7）正常業務交換機要繫結正常業務佇列（廢話）我這裡命名不規範，有歧義，反正記得dead.letter就是正常業務佇列哈～

（8）死信交換機繫結正常業務佇列和死信佇列

（9）測試：首先發送一條訊息去dead.letter佇列，沒有任何消費者，過期時間十秒，看它會不會自己轉發到死信佇列

清晰看到目前正常業務佇列收到了訊息，死信佇列中有3條死信。此時dead.letter無消費，過期時間10秒，等待10秒～

清楚看到dead.letter訊息過期，同時進入到了dlx.queue死信佇列中。此時我們只要定義一些消費端監聽死信，執行我們的業務邏輯處理即可。

這裡是基於MQ管理介面的簡單使用，程式碼和配置的用法稍後再發，但是反正流程和效果和應用場景大概就是這樣，現在網上總結這塊的資料不算多，希望能通過自己的分享幫助到更多需要用到的人～感恩～