一口氣說出Java 6種延時隊列的實現方法

如何實現延時隊列？
下邊會介紹多種實現延時隊列的思路，文末提供有幾種實現方式的 github 地址。其實哪種方式都沒有絕對的好與壞，只是看把它用在什麼業務場景中，技術這東西沒有最好的只有最合適的。
一、延時隊列的應用
什麼是延時隊列？顧名思義：首先它要具有隊列的特性，再給它附加一個延遲消費隊列消息的功能，也就是說可以指定隊列中的消息在哪個時間點被消費。
延時隊列在項目中的應用還是比較多的，尤其像電商類平臺：
1、訂單成功後，在30分鐘內沒有支付，自動取消訂單
2、外賣平臺發送訂餐通知，下單成功後60s給用戶推送短信。
3、如果訂單一直處於某一個未完結狀態時，及時處理關單，並退還庫存
4、淘寶新建商戶一個月內還沒上傳商品信息，將凍結商鋪等
。。。。
上邊的這些場景都可以應用延時隊列解決。
二、延時隊列的實現
我個人一直秉承的觀點：工作上能用 JDK 自帶 API 實現的功能，就不要輕易自己重複造輪子，或者引入三方中間件。一方面自己封裝很容易出問題（大佬除外），再加上調試驗證產生許多不必要的工作量；另一方面一旦接入三方的中間件就會讓系統複雜度成倍的增加，維護成本也大大的增加。
1、DelayQueue 延時隊列
JDK 中提供了一組實現延遲隊列的 API ，位於 Java.util.concurrent 包下 DelayQueue 。
DelayQueue 是一個 BlockingQueue （無界阻塞）隊列，它本質就是封裝了一個 PriorityQueue （優先隊列）， PriorityQueue 內部使用 完全二叉堆 （不知道的自行了解哈）來實現隊列元素排序，我們在向 DelayQueue 隊列中添加元素時，會給元素一個 Delay （延遲時間）作為排序條件，隊列中最小的元素會優先放在隊首。隊列中的元素只有到了 Delay 時間才允許從隊列中取出。隊列中可以放基本數據類型或自定義實體類，在存放基本數據類型時，優先隊列中元素默認升序排列，自定義實體類就需要我們根據類屬性值比較計算了。
先簡單實現一下看看效果，添加三個 order 入隊 DelayQueue ，分別設置訂單在當前時間的 5秒 、 10秒 、 15秒 後取消。
要實現 DelayQueue 延時隊列，隊中元素要 implements Delayed 接口，這哥接口裡只有一個 getDelay 方法，用於設置延期時間。 Order 類中 compareTo 方法負責對隊列中的元素進行排序。
public class Order implements Delayed { /** * 延遲時間 */ @JsonFormat(locale = "zh", timezone = "GMT+8", pattern = "yyyy-MM-dd HH:mm:ss") private long time; String name; public Order(String name, long time, TimeUnit unit) { this.name = name; this.time = System.currentTimeMillis() + (time > 0 ? unit.toMillis(time) : 0); } @Override public long getDelay(TimeUnit unit) { return time - System.currentTimeMillis(); } @Override public int compareTo(Delayed o) { Order Order = (Order) o; long diff = this.time - Order.time; if (diff <= 0) { return -1; } else { return 1; } } }
DelayQueue 的 put 方法是線程安全的，因為 put 方法內部使用了 ReentrantLock 鎖進行線程同步。 DelayQueue 還提供了兩種出隊的方法 poll() 和 take() ， poll() 為非阻塞獲取，沒有到期的元素直接返回null； take() 阻塞方式獲取，沒有到期的元素線程將會等待。
public class DelayQueueDemo { public static void main(String[] args) throws InterruptedException { Order Order1 = new Order("Order1", 5, TimeUnit.SECONDS); Order Order2 = new Order("Order2", 10, TimeUnit.SECONDS); Order Order3 = new Order("Order3", 15, TimeUnit.SECONDS); DelayQueue

/** * 消費消息 */ 

public void pollOrderQueue() { while (true) { Setset = jedis.zrangeWithScores(DELAY_QUEUE, 0, 0); String value = ((Tuple) set.toArray()[0]).getElement(); int score = (int) ((Tuple) set.toArray()[0]).getScore(); Calendar cal = Calendar.getInstance(); int nowSecond = (int) (cal.getTimeInMillis() / 1000); if (nowSecond >= score) { jedis.zrem(DELAY_QUEUE, value); System.out.println(sdf.format(new Date()) + " removed key:" + value); } if (jedis.zcard(DELAY_QUEUE) <= 0) { System.out.println(sdf.format(new Date()) + " zset empty "); return; } Thread.sleep(1000); } }
我們看到執行結果符合預期
2020-05-07 13:24:09 add finished.
2020-05-07 13:24:19 removed key:order1
2020-05-07 13:24:29 removed key:order2
2020-05-07 13:24:39 removed key:order3
2020-05-07 13:24:39 zset empty
4、Redis 過期回調
Redis 的 key 過期回調事件，也能達到延遲隊列的效果，簡單來說我們開啟監聽key是否過期的事件，一旦key過期會觸發一個callback事件。
修改 redis.conf 文件開啟 notify-keyspace-events Ex
notify-keyspace-events Ex
Redis 監聽配置，注入Bean RedisMessageListenerContainer
@Configuration public class RedisListenerConfig { @Bean RedisMessageListenerContainer container(RedisConnectionFactory connectionFactory) { RedisMessageListenerContainer container = new RedisMessageListenerContainer(); container.setConnectionFactory(connectionFactory); return container; } }
編寫Redis過期回調監聽方法，必須繼承 KeyExpirationEventMessageListener ，有點類似於MQ的消息監聽。
@Component public class RedisKeyExpirationListener extends KeyExpirationEventMessageListener { public RedisKeyExpirationListener(RedisMessageListenerContainer listenerContainer) { super(listenerContainer); } @Override public void onMessage(Message message, byte[] pattern) { String expiredKey = message.toString(); System.out.println("監聽到key：" + expiredKey + "已過期"); } }
到這代碼就編寫完成，非常的簡單，接下來測試一下效果，在 redis-cli 客戶端添加一個 key 並給定 3s 的過期時間。
set xiaofu 123 ex 3
在控制檯成功監聽到了這個過期的 key 。
監聽到過期的key為：xiaofu
5、RabbitMQ 延時隊列
利用 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 ，將死信重新轉發到能正常消費的關單隊列，直接監聽關單隊列處理關單邏輯即可。
發送消息時指定消息延遲的時間
public void send(String delayTimes) { amqpTemplate.convertAndSend("order.pay.exchange", "order.pay.queue","大家好我是延遲數據", message -> { // 設置延遲毫秒值 message.getMessageProperties().setExpiration(String.valueOf(delayTimes)); return message; }); } }
設置延遲隊列出現死信後的轉發規則
/** * 延時隊列 */ @Bean(name = "order.delay.queue") public Queue getMessageQueue() { return QueueBuilder .durable(RabbitConstant.DEAD_LETTER_QUEUE) // 配置到期後轉發的交換 .withArgument("x-dead-letter-exchange", "order.close.exchange") // 配置到期後轉發的路由鍵 .withArgument("x-dead-letter-routing-key", "order.close.queue") .build(); }
6、時間輪
前邊幾種延時隊列的實現方法相對簡單，比較容易理解，時間輪算法就稍微有點抽象了。 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 值的計算。
public HashedWheelTimer(ThreadFactory threadFactory, long tickDuration, TimeUnit unit, int ticksPerWheel) { this(threadFactory, tickDuration, unit, ticksPerWheel, true); }
TimerTask ：一個定時任務的實現接口，其中run方法包裝了定時任務的邏輯。
Timeout ：一個定時任務提交到 Timer 之後返回的句柄，通過這個句柄外部可以取消這個定時任務，並對定時任務的狀態進行一些基本的判斷。
Timer ：是 HashedWheelTimer 實現的父接口，僅定義瞭如何提交定時任務和如何停止整個定時機制。
public class NettyDelayQueue { public static void main(String[] args) { final Timer timer = new HashedWheelTimer(Executors.defaultThreadFactory(), 5, TimeUnit.SECONDS, 2); //定時任務 TimerTask task1 = new TimerTask() { public void run(Timeout timeout) throws Exception { System.out.println("order1 5s 後執行 "); timer.newTimeout(this, 5, TimeUnit.SECONDS);//結束時候再次註冊 } }; timer.newTimeout(task1, 5, TimeUnit.SECONDS); TimerTask task2 = new TimerTask() { public void run(Timeout timeout) throws Exception { System.out.println("order2 10s 後執行"); timer.newTimeout(this, 10, TimeUnit.SECONDS);//結束時候再註冊 } }; timer.newTimeout(task2, 10, TimeUnit.SECONDS); //延遲任務 timer.newTimeout(new TimerTask() { public void run(Timeout timeout) throws Exception { System.out.println("order3 15s 後執行一次"); } }, 15, TimeUnit.SECONDS); } }
從執行的結果看， order3 、 order3 延時任務只執行了一次，而 order2 、 order1 為定時任務，按照不同的週期重複執行。
order1 5s 後執行
order2 10s 後執行
order3 15s 後執行一次
order1 5s 後執行
order2 10s 後執行
總結
為了讓大家更容易理解，上邊的代碼寫的都比較簡單粗糙，幾種實現方式的 demo 已經都提交到 github 地址：https://github.com/chengxy-nds/delayqueue，感興趣的小夥伴可以下載跑一跑。
這篇文章肝了挺長時間，寫作一點也不比上班幹活輕鬆，查證資料反覆驗證demo的可行性，搭建各種 RabbitMQ 、 Redis 環境，只想說我太難了！