源起

大家可能都遇到過類似的需求:

• 生成訂單60秒后,給用戶發(fā)短信
• 下單之后15分鐘,如果用戶不付款就關(guān)閉訂單

解決方式

是的沒錯,我們用一種術(shù)語來描述上面的任務(wù),延時任務(wù).

那么針對于類似這樣的任務(wù),一般我們都是怎么處理的呢?

對于這種延時任務(wù),我們一般有以下的4中解決方式:

• 利用quartz等定時任務(wù)
• delayQueue
• wheelTimer
• rabbitMq的延遲隊列

下面就讓我們一起看一下這四種方式各自的優(yōu)劣。

利用quartz等定時任務(wù)

相信目前還有很多的公司依然沿用著這種做法,那么利用quartz怎么解決這個延時任務(wù)的問題呢？

具體的方式就是這樣的,比如我們有個下單15分鐘后用戶不付款就關(guān)閉訂單的任務(wù).我的訂單是存儲在mysql的一個表里,表里會有各種狀態(tài)和創(chuàng)建時間.
利用quartz來設(shè)定一個定時任務(wù),我們暫時設(shè)置為每5分鐘掃描一次.掃描的條件為未付款并且當(dāng)前時間大于創(chuàng)建時間超過15分鐘.然后我們再去逐一的操作每一條數(shù)據(jù).

優(yōu)點： 簡單易用,可以利用quartz的分布式特性輕易的進行橫向擴展。

缺點： 需要掃表會增加程序負荷、任務(wù)執(zhí)行不夠準時。

利用jdk自帶的delayQueue

上面我們已經(jīng)說過了用quartz解決這個辦法,現(xiàn)在我們這里引入了新的東東,就是jdk自帶的delayQueue.

那么究竟什么是delayQueue呢？

DelayQueue是java.util.concurrent中提供的一個很有意思的類。很巧妙，非常棒！但是java doc和Java SE 5.0的source中都沒有提供Sample。在ScheduledThreadPoolExecutor源碼時，發(fā)現(xiàn)DelayQueue的妙用?？梢赃@么說，DelayQueue是一個使用優(yōu)先隊列（PriorityQueue）實現(xiàn)的BlockingQueue，優(yōu)先隊列的比較基準值是時間（關(guān)于DelayQueue的源碼解析可以看我之前的文章delayQueue原理理解之源碼解析）

怎么使用delayQueue呢？

DelayQueue主要用于放置實現(xiàn)了Delay接口的對象，其中的對象只能在其時刻到期時才能從隊列中取走。這種隊列是有序的，即隊頭的延遲到期時間最短。如果沒有任何延遲到期，那么久不會有任何頭元素，并且poll()將返回null（正因為這樣，你不能將null放置到這種隊列中）

也就是說我們只需要把我們需要延遲觸發(fā)的任務(wù)構(gòu)建完畢放到delayQueue中，然后構(gòu)建一個消費者不斷的去取到期的任務(wù),進行處理就好.

優(yōu)點： 效率高,任務(wù)觸發(fā)時間延遲低。

缺點： 復(fù)雜度比quartz要高,自己要處理分布式橫向擴展的問題,因為數(shù)據(jù)是放在內(nèi)存里,需要自己寫持久化的備案以達到高可用。

利用wheelTimer

netty中的Timer管理，使用了的Hashed time Wheel的模式，Time Wheel翻譯為時間輪，是用于實現(xiàn)定時器timer的經(jīng)典算法。

HashWheelTimer的原理

時間輪算法的原理如圖所示：

時間輪算法的原理

可以將 HashedWheelTimer 理解為一個 Set<Task>[] 數(shù)組, 圖中每個槽位(slot)表示一個 Set<Task>

HashedWheelTimer 有兩個重要參數(shù)

tickDuration: 每 tick 一次的時間間隔, 每 tick 一次就會到達下一個槽位

ticksPerWheel: 輪中的 slot 數(shù)

上圖就是一個 ticksPerWheel = 8 的時間輪, 假如說 tickDuration = 100 ms, 則 800ms 可以走完一圈

在 timer.start() 以后, 便開始 tick, 每 tick 一次, timer 會將記錄總的 tick 次數(shù) ticks

我們加入一個新的超時任務(wù)時, 會根據(jù)超時的任務(wù)的超時時間與時間輪開始時間算出來它應(yīng)該在的槽位.

怎么使用WheelTimer呢？

在netty中已經(jīng)有了時間輪算法的實現(xiàn)HashWheelTimer,HashWheelTimer的使用非常的簡單:先new一個HashedWheelTimer，然后調(diào)用它的newTimeout方法傳遞相應(yīng)的延時任務(wù)就ok了。

下面是newTimeout的聲明：

    /**
     * Schedules the specified {@link TimerTask} for one-time execution after
     * the specified delay.
     *
     * @return a handle which is associated with the specified task
     *
     * @throws IllegalStateException if this timer has been
     *                               {@linkplain #stop() stopped} already
     */
    Timeout newTimeout(TimerTask task, long delay, TimeUnit unit);

這個方法需要一個TimerTask對象以知道當(dāng)時間到時要執(zhí)行什么邏輯，然后需要delay時間數(shù)值和TimeUnit時間的單位，像下面的例子中，我們在timer到期后會打印字符串，第一個任務(wù)是5秒后開始執(zhí)行，第二個10秒后開始執(zhí)行。

public class HashWheelTimerTest {
    public static void main(String[] argv) {
        final Timer timer = new HashedWheelTimer();
        timer.newTimeout(new TimerTask() {
            public void run(Timeout timeout) throws Exception {
                System.out.println("timeout 5");
            }
        }, 5, TimeUnit.SECONDS);
        timer.newTimeout(new TimerTask() {
            public void run(Timeout timeout) throws Exception {
                System.out.println("timeout 10");
            }
        }, 10, TimeUnit.SECONDS);
    }
}

優(yōu)點： 效率高,根據(jù)樓主自己寫的測試,在大量高負荷的任務(wù)堆積的情況下,HashWheelTimer基本要比delayQueue低上一倍的延遲率.netty中也有了時間輪算法的實現(xiàn),實現(xiàn)難度低

缺點： 內(nèi)存占用相對較高,對時間精度要求相對不高.和delayQueue有著相同的問題,自己要處理分布式橫向擴展的問題,因為數(shù)據(jù)是放在內(nèi)存里,需要自己寫持久化的備案以達到高可用。

rabbitMq的延遲隊列

大家都知道rabbitmq是一個消息隊列,同時因為其天然的分布式特性的支持已經(jīng)極高的消息處理效率深受大家的喜愛.那么大家應(yīng)該不知道他也是可以用來處理我們的延時任務(wù)的.

如何使用rabbitMq的延遲隊列

• AMQP和RabbitMQ本身沒有直接支持延遲隊列功能，但是可以通過以下特性模擬出延遲隊列的功能。
• RabbitMQ可以針對Queue和Message設(shè)置 x-message-tt，來控制消息的生存時間，如果超時，則消息變?yōu)閐ead letter
• lRabbitMQ的Queue可以配置x-dead-letter-exchange 和x-dead-letter-routing-key（可選）兩個參數(shù)，用來控制隊列內(nèi)出現(xiàn)了deadletter，則按照這兩個參數(shù)重新路由。
• 結(jié)合以上兩個特性，就可以模擬出延遲消息的功能

具體實現(xiàn)可參照官方文檔:
http://www.rabbitmq.com/ttl.html
http://www.rabbitmq.com/dlx.html

優(yōu)點： 高效,可以利用rabbitmq的分布式特性輕易的進行橫向擴展,消息支持持久化增加了可靠性。

缺點： 本身的易用度要依賴于rabbitMq的運維.因為要引用rabbitMq,所以復(fù)雜度和成本變高