一、背景介紹
1、什麼是延遲隊列？
顧名思義，延遲隊列是指被延遲消費的隊列。而一般的隊列，消息一旦入隊了之後就會被消費者馬上消費。
2、應用場景分析
1）延遲消費
- 在訂單系統中，一個用戶下單之後通常有30分鐘的時間進行支付，如果30分鐘之內沒有支付成功，那麼這個訂單將進行異常處理（如：關閉訂單），這時就可以使用延遲隊列來處理這些訂單
- 還有其它一些常用的應用場景，如：物聯網中的延時處理、新註冊用戶的活躍度調查……
2）延遲重試
- 主要是處理一些異常信息，如：發送失敗、消費失敗，可能當時由於網絡抖動的問題，暫時無法訪問，需要延遲再進行重試（重新發送，重新消費）
如果不使用延遲隊列，那麼我們只能採用定時任務，輪訓數據庫，方法簡單好用，但性能底下，在高併發情況下容易弄死數據庫，間隔時間不好設置，時間過大，影響精度，過小影響性能，而且做不到按超時的時間順序處理。
既然延遲隊列這麼好，我們怎樣來實現延遲隊列呢，本文將深入講解延遲隊列的實現原理，並實戰演練延遲隊列的應用
二、實現思路
1、技術框架選擇
SpringBoot、RabbitMQ、死信隊列、延遲隊列
2、核心概念
1）死信隊列
其實前面我們已經詳細介紹了死信隊列及其應用，這裡再簡單介紹一下：
DLX（Dead Letter Exchange）又死信郵箱、死信交換機。DLX就是一個普通的交換機，和一般的交換機沒有任何區別。
當消息在一個隊列中變成死信（dead message）時，通過這個交換機將死信發送到死信隊列中（指定好相關參數，rabbitmq會自動發送）。
什麼是死信呢？什麼樣的消息會變成死信呢？
- 消息被拒絕（basic.reject或basic.nack）並且requeue=false.
- 消息TTL過期
- 隊列達到最大長度（隊列滿了，無法再添加數據到mq中）
2）消息TTL/隊列TTL（Time To Live 過期時間）
- 隊列TTL：通過隊列的屬性來設置TTL，隊列中的所有消息都有相同的過期時間
- 消息TTL：通過消息的本身屬性來設置TTL，每條消息的TTL可以設置不同的過期時間
- 兩者同時使用：以較小的TTL為準
消息在隊列中的生存時間一旦超過設置的TTL，就會變成"死信"（Dead Message），如果綁定了死信隊列，這些死信變會進入死信隊列
隊列TTL與消息TTL的區別：處於性能上的考慮，兩者的處理方式是不同的
- 隊列TTL：一旦消息過期，就會立即從隊列中抹去（因為過期的消息肯定處於隊列的頭部）
- 消息TTL：即使消息過期，也不會馬上從隊列中抹去，因為每條消息是否過期是在即將投遞到消費者之前判定的
3）總結：
死信隊列+消息TTL=延遲隊列
3、流程圖
1）延遲消費
- 生產者發送消息到Queue_10s
- 設置Queue_10s的隊列TTL為10s
- 當消息過期後，經過DLX，進入Dead_Queue
- 消費者消費Dead_Queue中的消息
2）延遲重試
- 生產者發送消息到普通隊列，消費者正常消費隊列
- 生產者發送失敗，發送消息到Queue_20s，消息過期後，經過DLX，進入Dead_Queue，最為數據流重新發送
- 消費者消費失敗，發送消息到Queue_20s，消息過期後，經過DLX，進入Queue，消費者正常消費
四、實戰演練：在redis緩存實時更新中的應用
相關說明
- 我們這裡只演示延遲重試了，就不演示延遲消費了，以後如果遇到具體的場景案例中再介紹這一塊
- 我們使用隊列TTL來設置消息的TTL
1、廣告管理系統
模擬場景：生產者消息發送失敗的場景
1）隊列配置
- 配置過期隊列
- 建立過期隊列與死信隊列的關係
- 建立死信隊列
2）異常測試
發送異常——>進入過期隊列——>進入死信隊列——>後續再開一個消費者處理這些信息，確定這些信息為什麼會發送失敗，失敗原因是什麼
1、緩存服務系統
模擬場景：消費者息消費失敗的場景
1）隊列配置
- 配置過期隊列
- 建立過期隊列與正常隊列的關係
2）異常測試
消費異常——>進入過期隊列——>重新進入正常消費隊列——>重新被消費
代碼倉庫：https://gitee.com/jikeh/JiKeHCN-RELEASE.git
項目名：
spring-boot-ad（廣告管理系統）
spring-boot-rabbitmq-reliability-redis（緩存服務系統）
閱讀更多 極客慧 的文章
