我們在美團 APP 下單，假如沒有立即支付，進入訂單詳情會顯示倒計時，如果超過支付時間，訂單就會被自動取消。

這篇文章，筆者想以架構師的視角，深入剖析如何設計訂單超時自動取消的功能。

1 定時任務

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

方案流程：

1. 每隔 30 秒查詢數據庫，取出最近的 N 條未支付的訂單。

2. 遍歷查詢出來的訂單列表，判斷當前時間減去訂單的創建時間是否超過了支付超時時間，如果超時則對該訂單執行取消操作。

這種方案會間隔對數據庫造成一定的 IO 壓力，但工程實現相對簡單。

網上有很多的定時任務實現策略，我們可以簡單劃分為單機版和集群版。

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

因為業務系統都是集群部署，假如使用單機版模式，可能出現多臺不同機器實例同時執行任務的風險。

雖然我們可以通過加鎖的方式適當規避，從架構設計的角度但總是不夠優雅。

接下來，筆者會介紹親身經歷的三種集群定時任務。

01、 Quartz + JDBCJobStore

Quartz 是一款 Java 開源任務調度框架，它支持集群模式。

圖中，Quartz 的集群模式需要在數據庫中添加11張表，對業務系統有一定的侵入性。

筆者曾經服務的一家彩票公司，訂單調度中心就是使用 Quartz 的集群模式，實現日均百萬訂單的調度處理。

需要特別注意的是：

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

02、 Elastic-Job

ElasticJob 定位為輕量級無中心化解決方案，使用 jar 的形式提供分布式任務的協調服務。

ElasticJob 從本質上來講 ，底層任務調度還是通過 Quartz ，它的優勢在于可以依賴 Zookeeper 這個大殺器 ，將任務通過負載均衡算法分配給應用內的 Quartz Scheduler 容器，

舉例：應用A有五個任務需要執行，分別是 A，B，C，D，E。任務E需要分成四個子任務，應用部署在兩臺機器上。

圖中，應用 A 在啟動后， 5個任務通過 Zookeeper 協調后被分配到兩臺機器上，通過 Quartz Scheduler 分開執行不同的任務。

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

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

03、XXL-JOB

XXL-JOB 是一個使用最廣泛的分布式任務調度平臺。

業務系統和調度平臺分開部署，我們在調度中心上配置應用以及其定時任務，當任務需要執行時，調度平臺會觸發業務系統的任務，業務系統執行完任務之后，反饋給調度平臺任務執行的結果。

業務系統和調度平臺都可以水平擴展實現高可用，同時在調度平臺可以配置靈活的調度策略（比如重試機制等）。

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

2 延時消息

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

延時消息有三種技術選型：

1、消息隊列 RocketMQ

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

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

2、自研延遲服務

基于 RocketMQ 4 內置的延遲消息只能支持幾個固定的延遲級別，快手、滴滴開發了單獨的 Delay Server 來調度延遲消息。

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

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

3、Redis 延遲隊列

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

圖中，我們定義兩個集合：

1、zset 集合

生產者將任務信息發送到 zset 集合，value 是任務編號，score 是任務執行時間戳。

2、list 集合

守護線程檢測 zset 集合中到期的任務，若任務到期，將任務編號轉移到 list 集合 ， 消費者從 list 集合彈出任務，并執行任務邏輯。

筆者需要強調的是：

Redis 雖然可以實現延遲消息的功能，但 Redis 并不是真正意義上的消息隊列，在使用過程中還是有小概率會丟失消息。

3 并發口訣：一鎖二判三更新

不管我們使用定時任務還是延遲消息時，不可避免的會遇到并發執行任務的情況 （比如重復消費、調度重試等）。

當我們執行任務時，我們可以按照一鎖二判三更新這個口訣來處理。

1. 鎖定當前需要處理的訂單。

2. 判斷訂單是否已經更新過對應狀態了

3. 如果訂單之前沒有更新過狀態了，可以更新并完成相關業務邏輯，否則本次不能更新，也不能完成業務邏輯。

4. 釋放當前訂單的鎖。

4 總結

這篇文章，筆者總結了訂單超時自動取消方案的兩種流派：定時任務和延遲消息。

1、定時任務

1. 每隔 30 秒查詢數據庫，取出最近的 N 條未支付的訂單。

2. 遍歷查詢出來的訂單列表，判斷當前時間減去訂單的創建時間是否超過了支付超時時間，如果超時則對該訂單執行取消操作。

定時任務實現策略，我們可以簡單劃分為單機版和集群版。

筆者并不認可單機版，背八股文當然可以，訂單自動取消這個業務場景，生產環境還是要慎重。

集群版有三種方式：Quartz + JDBCJobStore、Elastic-Job 、XXL-JOB 。

每種方式各有優缺點，因為自研過任務調度系統的緣故，筆者更傾向于任務調度平臺 XXL-JOB 這種方式。

2、延遲消息

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

本文介紹了三種方式：消息隊列 RocketMQ、自研延遲服務、Redis 延遲隊列。

假如技術團隊基礎架構能力很強，筆者推薦使用 RocketMQ 或者自研延遲服務。

假如技術團隊僅僅想用輕量級的實現，可以選擇 Redis 延遲隊列。

不管是使用定時任務還是延遲消息，都需要考慮并發問題，請記住一個簡單的口訣：一鎖二判三更新。

最后，沒有完美的技術，只有最合適的技術。

做技術選型時，一定要結合業務場景，研發效率，運維成本，技術儲備等因素，做出合理的選擇。

轉自博客園https://www.cnblogs.com/makemylife/p/18025701