下邊會介紹多種實作延時隊列的思路，文末提供有幾種實作方式的 github位址。其實哪種方式都沒有絕對的好與壞，隻是看把它用在什麼業務場景中，技術這東西沒有最好的隻有最合适的。
什麼是延時隊列？顧名思義：首先它要具有隊列的特性，再給它附加一個延遲消費隊列消息的功能，也就是說可以指定隊列中的消息在哪個時間點被消費。
延時隊列在項目中的應用還是比較多的，尤其像電商類平台：
1、訂單成功後，在30分鐘内沒有支付，自動取消訂單
2、外賣平台發送訂餐通知，下單成功後60s給使用者推送短信。
3、如果訂單一直處于某一個未完結狀态時，及時處理關單，并退還庫存
4、淘寶建立商戶一個月内還沒上傳商品資訊，将當機商鋪等
。。。。
上邊的這些場景都可以應用延時隊列解決。
我個人一直秉承的觀點：工作上能用JDK自帶API實作的功能，就不要輕易自己重複造輪子，或者引入三方中間件。一方面自己封裝很容易出問題（大佬除外），再加上調試驗證産生許多不必要的工作量；另一方面一旦接入三方的中間件就會讓系統複雜度成倍的增加，維護成本也大大的增加。
JDK 中提供了一組實作延遲隊列的API，位于Java.util.concurrent包下DelayQueue。
DelayQueue是一個BlockingQueue（無界阻塞）隊列，它本質就是封裝了一個PriorityQueue（優先隊列），PriorityQueue内部使用完全二叉堆（不知道的自行了解哈）來實作隊列元素排序，我們在向DelayQueue隊列中添加元素時，會給元素一個Delay（延遲時間）作為排序條件，隊列中最小的元素會優先放在隊首。隊列中的元素隻有到了Delay時間才允許從隊列中取出。隊列中可以放基本資料類型或自定義實體類，在存放基本資料類型時，優先隊列中元素預設升序排列，自定義實體類就需要我們根據類屬性值比較計算了。
先簡單實作一下看看效果，添加三個order入隊DelayQueue，分别設定訂單在目前時間的5秒、10秒、15秒後取消。
要實作DelayQueue延時隊列，隊中元素要implements Delayed 接口，這哥接口裡隻有一個getDelay方法，用于設定延期時間。Order類中compareTo方法負責對隊列中的元素進行排序。
DelayQueue的put方法是線程安全的，因為put方法内部使用了ReentrantLock鎖進行線程同步。DelayQueue還提供了兩種出隊的方法 poll() 和 take() ， poll() 為非阻塞擷取，沒有到期的元素直接傳回null；take() 阻塞方式擷取，沒有到期的元素線程将會等待。
上邊隻是簡單的實作入隊與出隊的操作，實際開發中會有專門的線程，負責消息的入隊與消費。
執行後看到結果如下，Order1、Order2、Order3 分别在 5秒、10秒、15秒後被執行，至此就用DelayQueue實作了延時隊列。
Quartz一款非常經典任務排程架構，在Redis、RabbitMQ還未廣泛應用時，逾時未支付取消訂單功能都是由定時任務實作的。定時任務它有一定的周期性，可能很多單子已經逾時，但還沒到達觸發執行的時間點，那麼就會造成訂單處理的不夠及時。
引入quartz架構依賴包
在啟動類中使用@EnableScheduling注解開啟定時任務功能。
編寫一個定時任務，每個5秒執行一次。
Redis的資料結構Zset，同樣可以實作延遲隊列的效果，主要利用它的score屬性，redis通過score來為集合中的成員進行從小到大的排序。
通過zadd指令向隊列delayqueue 中添加元素，并設定score值表示元素過期的時間；向delayqueue 添加三個order1、order2、order3，分别是10秒、20秒、30秒後過期。
消費端輪詢隊列delayqueue， 将元素排序後取最小時間與目前時間比對，如小于目前時間代表已經過期移除key。
我們看到執行結果符合預期
Redis 的key過期回調事件，也能達到延遲隊列的效果，簡單來說我們開啟監聽key是否過期的事件，一旦key過期會觸發一個callback事件。
修改redis.conf檔案開啟notify-keyspace-events Ex
Redis監聽配置，注入Bean RedisMessageListenerContainer
編寫Redis過期回調監聽方法，必須繼承KeyExpirationEventMessageListener ，有點類似于MQ的消息監聽。
到這代碼就編寫完成，非常的簡單，接下來測試一下效果，在redis-cli用戶端添加一個key 并給定3s的過期時間。
在控制台成功監聽到了這個過期的key。
利用 RabbitMQ 做延時隊列是比較常見的一種方式，而實際上RabbitMQ 自身并沒有直接支援提供延遲隊列功能，而是通過 RabbitMQ 消息隊列的 TTL和 DXL這兩個屬性間接實作的。
先來認識一下 TTL和 DXL兩個概念：
Time To Live(TTL) ：
TTL 顧名思義：指的是消息的存活時間，RabbitMQ可以通過x-message-tt參數來設定指定Queue（隊列）和 Message（消息）上消息的存活時間，它的值是一個非負整數，機關為微秒。
RabbitMQ 可以從兩種次元設定消息過期時間，分别是隊列和消息本身
設定隊列過期時間，那麼隊列中所有消息都具有相同的過期時間。
設定消息過期時間，對隊列中的某一條消息設定過期時間，每條消息TTL都可以不同。
如果同時設定隊列和隊列中消息的TTL，則TTL值以兩者中較小的值為準。而隊列中的消息存在隊列中的時間，一旦超過TTL過期時間則成為Dead Letter（死信）。
Dead Letter Exchanges（DLX）
DLX即死信交換機，綁定在死信交換機上的即死信隊列。RabbitMQ的 Queue（隊列）可以配置兩個參數x-dead-letter-exchange 和 x-dead-letter-routing-key（可選），一旦隊列内出現了Dead Letter（死信），則按照這兩個參數可以将消息重新路由到另一個Exchange（交換機），讓消息重新被消費。
x-dead-letter-exchange：隊列中出現Dead Letter後将Dead Letter重新路由轉發到指定 exchange（交換機）。
x-dead-letter-routing-key：指定routing-key發送，一般為要指定轉發的隊列。
隊列出現Dead Letter的情況有：
消息或者隊列的TTL過期
隊列達到最大長度
消息被消費端拒絕（basic.reject or basic.nack）
下邊結合一張圖看看如何實作超30分鐘未支付關單功能，我們将訂單消息A0001發送到延遲隊列order.delay.queue，并設定x-message-tt消息存活時間為30分鐘，當到達30分鐘後訂單消息A0001成為了Dead Letter（死信），延遲隊列檢測到有死信，通過配置x-dead-letter-exchange，将死信重新轉發到能正常消費的關單隊列，直接監聽關單隊列處理關單邏輯即可。
發送消息時指定消息延遲的時間
設定延遲隊列出現死信後的轉發規則
前邊幾種延時隊列的實作方法相對簡單，比較容易了解，時間輪算法就稍微有點抽象了。kafka、netty都有基于時間輪算法實作延時隊列，下邊主要實踐Netty的延時隊列講一下時間輪是什麼原理。
先來看一張時間輪的原理圖，解讀一下時間輪的幾個基本概念
wheel ：時間輪，圖中的圓盤可以看作是鐘表的刻度。比如一圈round 長度為24秒，刻度數為 8，那麼每一個刻度表示 3秒。那麼時間精度就是 3秒。時間長度 / 刻度數值越大，精度越大。
當添加一個定時、延時任務A，假如會延遲25秒後才會執行，可時間輪一圈round 的長度才24秒，那麼此時會根據時間輪長度和刻度得到一個圈數 round和對應的指針位置 index，也是就任務A會繞一圈指向0格子上，此時時間輪會記錄該任務的round和 index資訊。當round=0，index=0 ，指針指向0格子 任務A并不會執行，因為 round=0不滿足要求。
是以每一個格子代表的是一些時間，比如1秒和25秒 都會指向0格子上，而任務則放在每個格子對應的連結清單中，這點和HashMap的資料有些類似。
Netty建構延時隊列主要用HashedWheelTimer，HashedWheelTimer底層資料結構依然是使用DelayedQueue，隻是采用時間輪的算法來實作。
下面我們用Netty 簡單實作延時隊列，HashedWheelTimer構造函數比較多，解釋一下各參數的含義。
ThreadFactory ：表示用于生成工作線程，一般采用線程池；
tickDuration和unit：每格的時間間隔，預設100ms；
ticksPerWheel：一圈下來有幾格，預設512，而如果傳入數值的不是2的N次方，則會調整為大于等于該參數的一個2的N次方數值，有利于優化hash值的計算。
TimerTask：一個定時任務的實作接口，其中run方法包裝了定時任務的邏輯。
Timeout：一個定時任務送出到Timer之後傳回的句柄，通過這個句柄外部可以取消這個定時任務，并對定時任務的狀态進行一些基本的判斷。
Timer：是HashedWheelTimer實作的父接口，僅定義了如何送出定時任務和如何停止整個定時機制。
從執行的結果看，order3、order3延時任務隻執行了一次，而order2、order1為定時任務，按照不同的周期重複執行。
為了讓大家更容易了解，上邊的代碼寫的都比較簡單粗糙，幾種實作方式的demo已經都送出到github 位址：https://github.com/chengxy-nds/delayqueue，感興趣的小夥伴可以下載下傳跑一跑。
這篇文章肝了挺長時間，寫作一點也不比上班幹活輕松，查證資料反複驗證demo的可行性，搭建各種RabbitMQ、Redis環境，隻想說我太難了！
可能寫的有不夠完善的地方，如哪裡有錯誤或者不明了的，歡迎大家踴躍指正！！！