1 定時任務(wù)

首先，我們非常自然的想到定時任務(wù)的方案。

方案流程：

每隔 30 秒查詢數(shù)據(jù)庫，取出最近的 N 條未支付的訂單。
遍歷查詢出來的訂單列表，判斷當(dāng)前時間減去訂單的創(chuàng)建時間是否超過了支付超時時間，如果超時則對該訂單執(zhí)行取消操作。

這種方案會間隔對數(shù)據(jù)庫造成一定的 IO 壓力，但工程實現(xiàn)相對簡單。

網(wǎng)上有很多的定時任務(wù)實現(xiàn)策略，我們可以簡單劃分為單機版和集群版。

筆者曾負責(zé)過彩票訂單、專車訂單等業(yè)務(wù)，在這些業(yè)務(wù)場景里，都沒有使用單機版定時任務(wù)。

因為業(yè)務(wù)系統(tǒng)都是集群部署，假如使用單機版模式，可能出現(xiàn)多臺不同機器實例同時執(zhí)行任務(wù)的風(fēng)險。

雖然我們可以通過加鎖的方式適當(dāng)規(guī)避，從架構(gòu)設(shè)計的角度但總是不夠優(yōu)雅。

接下來，筆者會介紹親身經(jīng)歷的三種集群定時任務(wù)。

01、 Quartz + JDBCJobStore

Quartz 是一款 Java 開源任務(wù)調(diào)度框架，它支持集群模式。

圖中，Quartz 的集群模式需要在數(shù)據(jù)庫中添加11張表，對業(yè)務(wù)系統(tǒng)有一定的侵入性。

筆者曾經(jīng)服務(wù)的一家彩票公司，訂單調(diào)度中心就是使用 Quartz 的集群模式，實現(xiàn)日均百萬訂單的調(diào)度處理。

需要特別注意的是：

基于底層數(shù)據(jù)庫悲觀鎖的機制， Quartz 的集群模式性能并不高，假如執(zhí)行頻率高的任務(wù)數(shù)超過一定數(shù)量級，可能存在一定的問題。

02、 Elastic-Job

ElasticJob 定位為輕量級無中心化解決方案，使用 jar 的形式提供分布式任務(wù)的協(xié)調(diào)服務(wù)。

ElasticJob 從本質(zhì)上來講，底層任務(wù)調(diào)度還是通過 Quartz ，它的優(yōu)勢在于可以依賴 Zookeeper 這個大殺器，將任務(wù)通過負載均衡算法分配給應(yīng)用內(nèi)的 Quartz Scheduler 容器，

舉例：應(yīng)用A有五個任務(wù)需要執(zhí)行，分別是 A，B，C，D，E。任務(wù)E需要分成四個子任務(wù)，應(yīng)用部署在兩臺機器上。

圖中，應(yīng)用 A 在啟動后， 5個任務(wù)通過 Zookeeper 協(xié)調(diào)后被分配到兩臺機器上，通過 Quartz Scheduler 分開執(zhí)行不同的任務(wù)。

相比 Quartz 集群模式，ElasticJob 的可擴展性更高，同時性能也更好。

但是 ElasticJob 的控制臺非常粗糙，主要原因還是基于它的實現(xiàn)機制（Quartz + zookeeper），所以 ElasticJob 更多的還是定位于框架，而不是一個調(diào)度平臺。

03、XXL-JOB

XXL-JOB 是一個使用最廣泛的分布式任務(wù)調(diào)度平臺。

業(yè)務(wù)系統(tǒng)和調(diào)度平臺分開部署，我們在調(diào)度中心上配置應(yīng)用以及其定時任務(wù)，當(dāng)任務(wù)需要執(zhí)行時，調(diào)度平臺會觸發(fā)業(yè)務(wù)系統(tǒng)的任務(wù)，業(yè)務(wù)系統(tǒng)執(zhí)行完任務(wù)之后，反饋給調(diào)度平臺任務(wù)執(zhí)行的結(jié)果。

業(yè)務(wù)系統(tǒng)和調(diào)度平臺都可以水平擴展實現(xiàn)高可用，同時在調(diào)度平臺可以配置靈活的調(diào)度策略（比如重試機制等）。

筆者非常認可這種模式。很多公司比如神州專車、美團都有自己自研的任務(wù)調(diào)度平臺。這種模式非常適合多團隊協(xié)作，便于調(diào)度任務(wù)的統(tǒng)一管理。

2 延時消息

延時消息是一種非常優(yōu)雅的模式。訂單服務(wù)生成訂單后，發(fā)送一條延時消息到消息隊列。消息隊列在消息到達支付過期時間時，將消息投遞給消費者，執(zhí)行取消訂單的邏輯。

延時消息有三種技術(shù)選型：

1、消息隊列 RocketMQ

RocketMQ 4.X 版本默認支持 18 個 level 的延遲消息，通過 broker 端的 messageDelayLevel 配置項確定的。

RocketMQ 5.X 版本支持任意時刻延遲消息，客戶端在構(gòu)造消息時提供了 3 個 API 來指定延遲時間或定時時間。

2、自研延遲服務(wù)

基于 RocketMQ 4 內(nèi)置的延遲消息只能支持幾個固定的延遲級別，快手、滴滴開發(fā)了單獨的 Delay Server 來調(diào)度延遲消息。

上圖這個結(jié)構(gòu)沒有直接將延遲消息發(fā)到 Delay Server，而是更換 Topic 以后存入 RocketMQ。這樣的好處是可以復(fù)用現(xiàn)有的消息發(fā)送接口（以及上面的所有擴展能力）。對業(yè)務(wù)來說，只需要在構(gòu)造消息的時候額外指定一個延遲時間字段即可，其它用法都不變。

自研單獨的 Delay Server 不僅可以適配 RocketMQ 4.X , 也可以適配 Kafka ，說實話，這個是一個非常實用的方案。

3、Redis 延遲隊列

Redis 延遲隊列是一個輕量級的解決方案，開源成熟的實現(xiàn)是 Redission 。