我們在美團(tuán) APP 下單，假如沒有立即支付，進(jìn)入訂單詳情會顯示倒計(jì)時(shí)，如果超過支付時(shí)間，訂單就會被自動(dòng)取消。

這篇文章，筆者想以架構(gòu)師的視角，深入剖析如何設(shè)計(jì)訂單超時(shí)自動(dòng)取消的功能。

1 定時(shí)任務(wù)

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

方案流程：

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

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

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

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

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

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

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

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

01、 Quartz + JDBCJobStore

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

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

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

需要特別注意的是：

基于底層數(shù)據(jù)庫悲觀鎖的機(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 這個(gè)大殺器 ，將任務(wù)通過負(fù)載均衡算法分配給應(yīng)用內(nèi)的 Quartz Scheduler 容器，

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

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

相比 Quartz 集群模式，ElasticJob 的可擴(kuò)展性更高，同時(shí)性能也更好。

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

03、XXL-JOB

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

業(yè)務(wù)系統(tǒng)和調(diào)度平臺分開部署，我們在調(diào)度中心上配置應(yīng)用以及其定時(shí)任務(wù)，當(dāng)任務(wù)需要執(zhí)行時(shí)，調(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)度平臺都可以水平擴(kuò)展實(shí)現(xiàn)高可用，同時(shí)在調(diào)度平臺可以配置靈活的調(diào)度策略（比如重試機(jī)制等）。

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

2 延時(shí)消息

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

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

1、消息隊(duì)列 RocketMQ

RocketMQ 4.X 版本默認(rèn)支持 18 個(gè) level 的延遲消息， 通過 broker 端的 messageDelayLevel 配置項(xiàng)確定的。

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

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

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

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

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

3、Redis 延遲隊(duì)列

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

圖中，我們定義兩個(gè)集合：

1、zset 集合

生產(chǎn)者將任務(wù)信息發(fā)送到 zset 集合，value 是任務(wù)編號，score 是任務(wù)執(zhí)行時(shí)間戳。

2、list 集合

守護(hù)線程檢測 zset 集合中到期的任務(wù)，若任務(wù)到期，將任務(wù)編號轉(zhuǎn)移到 list 集合 ， 消費(fèi)者從 list 集合彈出任務(wù)，并執(zhí)行任務(wù)邏輯。

筆者需要強(qiáng)調(diào)的是：

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

3 并發(fā)口訣：一鎖二判三更新

不管我們使用定時(shí)任務(wù)還是延遲消息時(shí)，不可避免的會遇到并發(fā)執(zhí)行任務(wù)的情況 （比如重復(fù)消費(fèi)、調(diào)度重試等）。

當(dāng)我們執(zhí)行任務(wù)時(shí)，我們可以按照一鎖二判三更新這個(gè)口訣來處理。

1. 鎖定當(dāng)前需要處理的訂單。

2. 判斷訂單是否已經(jīng)更新過對應(yīng)狀態(tài)了

3. 如果訂單之前沒有更新過狀態(tài)了，可以更新并完成相關(guān)業(yè)務(wù)邏輯，否則本次不能更新，也不能完成業(yè)務(wù)邏輯。

4. 釋放當(dāng)前訂單的鎖。

4 總結(jié)

這篇文章，筆者總結(jié)了訂單超時(shí)自動(dòng)取消方案的兩種流派：定時(shí)任務(wù)和延遲消息。

1、定時(shí)任務(wù)

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

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

定時(shí)任務(wù)實(shí)現(xiàn)策略，我們可以簡單劃分為單機(jī)版和集群版。

筆者并不認(rèn)可單機(jī)版，背八股文當(dāng)然可以，訂單自動(dòng)取消這個(gè)業(yè)務(wù)場景，生產(chǎn)環(huán)境還是要慎重。

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

每種方式各有優(yōu)缺點(diǎn)，因?yàn)樽匝羞^任務(wù)調(diào)度系統(tǒng)的緣故，筆者更傾向于任務(wù)調(diào)度平臺 XXL-JOB 這種方式。

2、延遲消息

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

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

假如技術(shù)團(tuán)隊(duì)基礎(chǔ)架構(gòu)能力很強(qiáng)，筆者推薦使用 RocketMQ 或者自研延遲服務(wù)。

假如技術(shù)團(tuán)隊(duì)僅僅想用輕量級的實(shí)現(xiàn)，可以選擇 Redis 延遲隊(duì)列。

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

最后，沒有完美的技術(shù)，只有最合適的技術(shù)。

做技術(shù)選型時(shí)，一定要結(jié)合業(yè)務(wù)場景，研發(fā)效率，運(yùn)維成本，技術(shù)儲備等因素，做出合理的選擇。

轉(zhuǎn)自博客園https://www.cnblogs.com/makemylife/p/18025701