您好,登錄后才能下訂單哦!
這篇文章主要講解了Java6種延時隊列的實現方法,內容清晰明了,對此有興趣的小伙伴可以學習一下,相信大家閱讀完之后會有幫助。
五一期間原計劃是寫兩篇文章,看一本技術類書籍,結果這五天由于自律性過于差,禁不住各種誘惑,我連電腦都沒打開過,計劃完美宣告失敗。所以在這能看出和大佬之間的差距,人家沒白沒夜的更文,比你優秀的人比你更努力,難以望其項背,真是讓我自愧不如。
知恥而后勇,這不逼著自己又學起來了,個人比較喜歡一些實踐類的東西,既學習到知識又能讓技術落地,能搞出個demo
最好,本來不知道該分享什么主題,好在最近項目緊急招人中,而我有幸做了回面試官,就給大家整理分享一道面試題:“如何實現延時隊列?”。
下邊會介紹多種實現延時隊列的思路,文末提供有幾種實現方式的 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<Order> delayQueue = new DelayQueue<>(); delayQueue.put(Order1); delayQueue.put(Order2); delayQueue.put(Order3); System.out.println("訂單延遲隊列開始時間:" + LocalDateTime.now().format(DateTimeFormatter.ofPattern("yyyy-MM-dd HH:mm:ss"))); while (delayQueue.size() != 0) { /** * 取隊列頭部元素是否過期 */ Order task = delayQueue.poll(); if (task != null) { System.out.format("訂單:{%s}被取消, 取消時間:{%s}\n", task.name, LocalDateTime.now().format(DateTimeFormatter.ofPattern("yyyy-MM-dd HH:mm:ss"))); } Thread.sleep(1000); } } }
上邊只是簡單的實現入隊與出隊的操作,實際開發中會有專門的線程,負責消息的入隊與消費。
執行后看到結果如下,Order1
、Order2
、Order3
分別在 5秒
、10秒
、15秒
后被執行,至此就用DelayQueue
實現了延時隊列。
訂單延遲隊列開始時間:2020-05-06 14:59:09
訂單:{Order1}被取消, 取消時間:{2020-05-06 14:59:14}
訂單:{Order2}被取消, 取消時間:{2020-05-06 14:59:19}
訂單:{Order3}被取消, 取消時間:{2020-05-06 14:59:24}
2、Quartz 定時任務
Quartz
一款非常經典任務調度框架,在Redis
、RabbitMQ
還未廣泛應用時,超時未支付取消訂單功能都是由定時任務實現的。定時任務它有一定的周期性,可能很多單子已經超時,但還沒到達觸發執行的時間點,那么就會造成訂單處理的不夠及時。
引入quartz
框架依賴包
<dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-quartz</artifactId> </dependency>
在啟動類中使用@EnableScheduling
注解開啟定時任務功能。
@EnableScheduling @SpringBootApplication public class DelayqueueApplication { public static void main(String[] args) { SpringApplication.run(DelayqueueApplication.class, args); } }
編寫一個定時任務,每個5秒執行一次。
@Component public class QuartzDemo { //每隔五秒 @Scheduled(cron = "0/5 * * * * ? ") public void process(){ System.out.println("我是定時任務!"); } }
3、Redis sorted set
Redis
的數據結構Zset
,同樣可以實現延遲隊列的效果,主要利用它的score
屬性,redis
通過score
來為集合中的成員進行從小到大的排序。
通過zadd
命令向隊列delayqueue
中添加元素,并設置score
值表示元素過期的時間;向delayqueue
添加三個order1
、order2
、order3
,分別是10秒
、20秒
、30秒
后過期。
zadd delayqueue 3 order3
消費端輪詢隊列delayqueue
, 將元素排序后取最小時間與當前時間比對,如小于當前時間代表已經過期移除key
。
/** * 消費消息 */ public void pollOrderQueue() { while (true) { Set<Tuple> set = 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
過期下邊結合一張圖看看如何實現超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 后執行
看完上述內容,是不是對Java6種延時隊列的實現方法有進一步的了解,如果還想學習更多內容,歡迎關注億速云行業資訊頻道。
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。