大家好，我是老三，大家對電商購物應(yīng)該都比較熟悉了，我們應(yīng)該注意到，在下單之后，通常會有一個倒計時，如果超過支付時間，訂單就會被自動取消。

下單

今天，我們來聊聊訂單超時未支付自動取消的幾種方案。

1.定時任務(wù)

這是最容易想到的辦法，定時任務(wù)去輪詢數(shù)據(jù)庫，取消即將超時的訂單。

訂單輪詢

定時任務(wù)實現(xiàn)方式有很多種，大概可以分為兩類：本地定時任務(wù)和分布式定時任務(wù)。

定時任務(wù)實現(xiàn)

本地定時任務(wù)，適用于單機(jī)版的業(yè)務(wù)系統(tǒng)，實現(xiàn)方式非常多樣：

• 永動機(jī)線程：開啟一個線程，通過sleep去完成定時，一些開源中間件的某些定時任務(wù)是通過這種方式實現(xiàn)的。
• JDK Timer：JDK提供了Timer API，也提供了很多周期性的方法。
• 延遲線程池：JDK還提供了延遲線程池ScheduledExecutorService，API和Timer類似。
• Spring Task：Sprig框架也提供了一些定時任務(wù)的實現(xiàn)，使用起來更加簡單。
• Quartz：Quartz框架更進(jìn)一步，提供了可以動態(tài)配置的線程池。

分布式定時任務(wù)：適用于分布式的業(yè)務(wù)系統(tǒng)，主要的實現(xiàn)框架有兩種：

• xxl-job：大眾點評的許雪里開源的，一款基于MySQL的輕量級分布式定時任務(wù)框架。
• elastic-job：當(dāng)當(dāng)開發(fā)的彈性分布式任務(wù)調(diào)度系統(tǒng)，功能很強(qiáng)大，相對重一些。

定時任務(wù)實現(xiàn)的優(yōu)點是開發(fā)起來比較簡單，但是它也有一些缺點：

• 對數(shù)據(jù)庫的壓力很大，定時任務(wù)造成人為的波峰，執(zhí)行的時刻數(shù)據(jù)庫的壓力會陡增
• 計時不準(zhǔn)，定時任務(wù)做不到非常精確的時間控制，比如半小時訂單過期，但是定時任務(wù)很難卡準(zhǔn)這個點

2.被動取消

在文章開頭的那個倒計時器，大家覺得是怎么做的呢？一般是客戶端計時+服務(wù)端檢查。

什么意思呢？就是這個倒計時由客戶端去做，但是客戶端定時去服務(wù)端檢查，修正倒計時的時間。

那么，這個訂單超時自動取消，也可以由客戶端去做：

• 用戶留在收銀臺的時候，客戶端倒計時+主動查詢訂單狀態(tài)，服務(wù)端每次都去檢查一下訂單是否超時、剩余時間
• 用戶每次進(jìn)入訂單相關(guān)的頁面，查詢訂單的時候，服務(wù)端也檢查一下訂單是否超時

被動取消

這種方式實現(xiàn)起來也比較簡單，但是它也有缺點：

依賴客戶端，如果客戶端不發(fā)起請求，訂單可能永遠(yuǎn)沒法過期，一直占用庫存

當(dāng)然，也可以被動取消+定時任務(wù)，通過定時任務(wù)去做兜底的操作。

3.延時消息

第三種方案，就是利用延時消息了，可以使用RocketMQ、RabbitMQ、Kafka的延時消息，消息發(fā)送后，有一定延時才會投遞。

延時消息

我們用的就是這種，消息隊列采用的是RocketMQ，其實RocketMQ延時也是利用定時任務(wù)實現(xiàn)的。

使用延時消息的優(yōu)點是比較高效、好擴(kuò)展，缺點是引入了新的技術(shù)組件，增加了復(fù)雜度。

除了上面的三種，其實還有一些其它的方式，例如本地延遲隊列、時間輪算法、Redis過期監(jiān)聽……

但是我覺得，應(yīng)該不會有人真考慮過在生產(chǎn)上使用這些方法。

這里再給大家提個小問題，假如我們接入了一種支付方式，支付的周期非常長，我們需要延長訂單的有效時間，這種情況下，大家會怎么實現(xiàn)訂單超時未支付自動取消呢？

參考：

[1].Java中定時任務(wù)的6種實現(xiàn)方式，你知道幾種？:https://juejin.cn/post/6992719702032121864

[2].訂單超時未支付自動取消8種實現(xiàn)方案:https://blog.csdn.net/Anenan/article/details/126368753：?