如何設(shè)計(jì)訂單超時(shí)自動(dòng)取消
我們?cè)诿缊F(tuán) APP 下單，假如沒(méi)有立即支付，進(jìn)入訂單詳情會(huì)顯示倒計(jì)時(shí)，如果超過(guò)支付時(shí)間，訂單就會(huì)被自動(dòng)取消。
網(wǎng)上有很多八股文，很多方案其實(shí)并不太適合真實(shí)的業(yè)務(wù)場(chǎng)景。所以這篇文章，筆者想深入剖析如何設(shè)計(jì)訂單超時(shí)自動(dòng)取消的功能，希望能帶給大家一些啟發(fā)。
圖片
1 定時(shí)任務(wù)方案
首先，我們非常自然的想到定時(shí)任務(wù)的方案。
方案流程：
- 每隔 30 秒查詢數(shù)據(jù)庫(kù)，取出最近的 N 條未支付的訂單。
- 遍歷查詢出來(lái)的訂單列表，判斷當(dāng)前時(shí)間減去訂單的創(chuàng)建時(shí)間是否超過(guò)了支付超時(shí)時(shí)間，如果超時(shí)則對(duì)該訂單執(zhí)行取消操作。
定時(shí)任務(wù)方案工程實(shí)現(xiàn)相對(duì)簡(jiǎn)單，但這種方案會(huì)間隔對(duì)數(shù)據(jù)庫(kù)造成一定的 IO 壓力。特別是當(dāng)訂單量數(shù)據(jù)量非常高時(shí)，高頻次的查詢對(duì)數(shù)據(jù)庫(kù)的性能是個(gè)不小的考驗(yàn)。
定時(shí)任務(wù)方案從功能模塊角度來(lái)講，包含調(diào)度層和業(yè)務(wù)邏輯層兩部分。
圖片
網(wǎng)上有很多的定時(shí)任務(wù)實(shí)現(xiàn)策略，我們可以簡(jiǎn)單劃分為單機(jī)版和集群版。
2 定時(shí)任務(wù)方案：?jiǎn)螜C(jī)版
我們可以使用 Timer 、ScheduledEexcutorService、Quartz 非常容易的實(shí)現(xiàn)定時(shí)任務(wù)。
圖片
但筆者并不推薦使用單機(jī)版的方案，舉個(gè)簡(jiǎn)單的例子：
圖片
假設(shè)我們應(yīng)用 A 通過(guò) Quartz 調(diào)度三個(gè)定時(shí)任務(wù) A、B、C ，當(dāng)集群部署時(shí)，可能出現(xiàn)多臺(tái)不同機(jī)器實(shí)例同時(shí)執(zhí)行任務(wù)的風(fēng)險(xiǎn)。
此時(shí)，我們可以通過(guò)加鎖的方式適當(dāng)規(guī)避，見(jiàn)下圖：
圖片
但這種方式并不優(yōu)雅，同時(shí)定時(shí)任務(wù)應(yīng)用內(nèi)調(diào)度層會(huì)經(jīng)?？张?，我們預(yù)期是希望三個(gè)定時(shí)任務(wù) A、B、C 能均勻分布應(yīng)用 A的不同實(shí)例內(nèi)。
好，接下來(lái)，筆者會(huì)介紹親身經(jīng)歷的三種集群定時(shí)任務(wù)。
3 定時(shí)任務(wù)方案：集群版
圖片
3.1 Quartz + JDBCJobStore
Quartz 可以支持集群模式，集群模式需要在數(shù)據(jù)庫(kù)中添加11張表，對(duì)業(yè)務(wù)系統(tǒng)有一定的侵入性。
圖片
筆者曾經(jīng)服務(wù)的一家彩票公司，訂單調(diào)度中心就是使用 Quartz 的集群模式，實(shí)現(xiàn)日均百萬(wàn)訂單的調(diào)度處理。
需要特別注意的是：
基于底層數(shù)據(jù)庫(kù)悲觀鎖的機(jī)制，Quartz 的集群模式性能并不高，假如執(zhí)行頻率高的任務(wù)數(shù)超過(guò)達(dá)到一定數(shù)量，存在性能問(wèn)題。
3.1 Elastic-Job
ElasticJob 定位為輕量級(jí)無(wú)中心化解決方案，使用 jar 的形式提供分布式任務(wù)的協(xié)調(diào)服務(wù)。
ElasticJob 從本質(zhì)上來(lái)講 ，底層任務(wù)調(diào)度還是通過(guò) Quartz ，它的優(yōu)勢(shì)在于可以依賴(lài) Zookeeper 這個(gè)大殺器 ，將任務(wù)通過(guò)負(fù)載均衡算法分配給應(yīng)用內(nèi)的 Quartz Scheduler 容器，
舉例：應(yīng)用A有五個(gè)任務(wù)需要執(zhí)行，分別是 A，B，C，D，E。任務(wù)E需要分成四個(gè)子任務(wù)，應(yīng)用部署在兩臺(tái)機(jī)器上。
圖片
圖中，應(yīng)用 A 在啟動(dòng)后， 5個(gè)任務(wù)通過(guò) Zookeeper 協(xié)調(diào)后被分配到兩臺(tái)機(jī)器上，通過(guò) Quartz Scheduler 分開(kāi)執(zhí)行不同的任務(wù)。
相比 Quartz 集群模式，ElasticJob 的可擴(kuò)展性更高，同時(shí)因?yàn)槭潜镜貎?nèi)存存儲(chǔ) JOB，性能非常好。
但是 ElasticJob 的控制臺(tái)非常粗糙，主要原因還是基于它的實(shí)現(xiàn)機(jī)制 （Quartz + zookeeper）。
通過(guò)控制 zookeeper 節(jié)點(diǎn)來(lái)間接操作應(yīng)用內(nèi)任務(wù)執(zhí)行情況，但這樣非常不靈活，所以筆者認(rèn)為 ElasticJob 更多的還是定位于框架，而不是一個(gè)調(diào)度平臺(tái)。
3.3 任務(wù)調(diào)度平臺(tái)
筆者非常認(rèn)可任務(wù)調(diào)度平臺(tái)這種模式。XXL-JOB 是一個(gè)使用最廣泛的分布式任務(wù)調(diào)度平臺(tái)。
圖片
業(yè)務(wù)系統(tǒng)和調(diào)度平臺(tái)分開(kāi)部署，我們?cè)谡{(diào)度中心上配置應(yīng)用以及其定時(shí)任務(wù)，當(dāng)任務(wù)需要執(zhí)行時(shí)，調(diào)度平臺(tái)會(huì)觸發(fā)業(yè)務(wù)系統(tǒng)的任務(wù)，業(yè)務(wù)系統(tǒng)執(zhí)行完任務(wù)之后，反饋給調(diào)度平臺(tái)任務(wù)執(zhí)行的結(jié)果。
業(yè)務(wù)系統(tǒng)和調(diào)度平臺(tái)都可以水平擴(kuò)展實(shí)現(xiàn)高可用，同時(shí)在調(diào)度平臺(tái)可以配置靈活的調(diào)度策略（比如重試機(jī)制、廣播模式等）。
XXL-JOB 并不完美，因?yàn)榈讓右廊皇腔跀?shù)據(jù)庫(kù)悲觀鎖的機(jī)制，雖然通過(guò)時(shí)間輪的方式做了一定程度的優(yōu)化，但依然會(huì)有性能瓶頸。
很多公司比如神州專(zhuān)車(chē)、美團(tuán)都有自己自研的任務(wù)調(diào)度平臺(tái)。這種模式非常適合多團(tuán)隊(duì)協(xié)作，便于大規(guī)模調(diào)度任務(wù)的統(tǒng)一管理。
4 延時(shí)消息方案
延時(shí)消息是一種非常優(yōu)雅的模式。訂單服務(wù)生成訂單后，發(fā)送一條延時(shí)消息到消息隊(duì)列。消息隊(duì)列在消息到達(dá)支付過(guò)期時(shí)間時(shí)，將消息投遞給消費(fèi)者，消費(fèi)者收到消息之后，判斷訂單狀態(tài)是否為已支付，假如未支付，則執(zhí)行取消訂單的邏輯。
圖片
4.1 消息隊(duì)列 RocketMQ
RocketMQ 4.X 生產(chǎn)者發(fā)送延遲消息代碼如下：
Message msg = new Message();
msg.setTopic("TopicA");
msg.setTags("Tag");
msg.setBody("this is a delay message".getBytes());
//設(shè)置延遲level為5，對(duì)應(yīng)延遲1分鐘
msg.setDelayTimeLevel(5);
producer.send(msg);RocketMQ 4.X 版本默認(rèn)支持 18 個(gè) level 的延遲消息， 通過(guò) broker 端的 messageDelayLevel 配置項(xiàng)確定的。
圖片
RocketMQ 5.X 版本支持任意時(shí)刻延遲消息，客戶端在構(gòu)造消息時(shí)提供了 3 個(gè) API 來(lái)指定延遲時(shí)間或定時(shí)時(shí)間。
圖片
假如技術(shù)團(tuán)隊(duì)基礎(chǔ)架構(gòu)能力很強(qiáng)，筆者非常推薦使用 RocketMQ 5.X 的延遲消息功能。
4.2 自研延遲服務(wù)
基于 RocketMQ 4 內(nèi)置的延遲消息只能支持幾個(gè)固定的延遲級(jí)別，快手、滴滴開(kāi)發(fā)了單獨(dú)的 Delay Server 來(lái)調(diào)度延遲消息。
圖片
上圖這個(gè)結(jié)構(gòu)沒(méi)有直接將延遲消息發(fā)到 Delay Server，而是更換 Topic 以后存入 RocketMQ。這樣的好處是可以復(fù)用現(xiàn)有的消息發(fā)送接口（以及上面的所有擴(kuò)展能力）。對(duì)業(yè)務(wù)來(lái)說(shuō)，只需要在構(gòu)造消息的時(shí)候額外指定一個(gè)延遲時(shí)間字段即可，其它用法都不變。
自研單獨(dú)的 Delay Server 不僅可以適配 RocketMQ 4.X , 也可以適配 Kafka ，同時(shí)，也可以具有非常高的性能，說(shuō)實(shí)話，這個(gè)是一個(gè)非常實(shí)用且靈活的方案。
4.3 Redis 延遲隊(duì)列
Redis 延遲隊(duì)列是一個(gè)輕量級(jí)的解決方案，開(kāi)源成熟的實(shí)現(xiàn)是 Redission 。
圖片
圖中，我們定義兩個(gè)集合：
1、zset 集合
生產(chǎn)者將任務(wù)信息發(fā)送到 zset 集合，value 是任務(wù)編號(hào)，score 是任務(wù)執(zhí)行時(shí)間戳。
2、list 集合
守護(hù)線程檢測(cè) zset 集合中到期的任務(wù)，若任務(wù)到期，將任務(wù)編號(hào)轉(zhuǎn)移到 list 集合 ， 消費(fèi)者從 list 集合彈出任務(wù)，并執(zhí)行任務(wù)邏輯。
筆者需要強(qiáng)調(diào)的是：
Redis 雖然可以實(shí)現(xiàn)延遲消息的功能，但 Redis 并不是真正意義上的消息隊(duì)列，在使用過(guò)程中還是有小概率會(huì)丟失消息。
5 最佳實(shí)踐
5.1 并發(fā)口訣：一鎖二判三更新
不管我們使用定時(shí)任務(wù)還是延遲消息時(shí)，不可避免的會(huì)遇到并發(fā)執(zhí)行任務(wù)的情況 （比如重復(fù)消費(fèi)、調(diào)度重試等）。
當(dāng)我們執(zhí)行任務(wù)時(shí)，我們可以按照一鎖二判三更新這個(gè)口訣來(lái)處理。
- 鎖定當(dāng)前需要處理的訂單。
- 判斷訂單是否已經(jīng)更新過(guò)對(duì)應(yīng)狀態(tài)了
- 如果訂單之前沒(méi)有更新過(guò)狀態(tài)了，可以更新并完成相關(guān)業(yè)務(wù)邏輯，否則本次不能更新，也不能完成業(yè)務(wù)邏輯。
- 釋放當(dāng)前訂單的鎖。
圖片
偽代碼
5.2 兜底意識(shí) + 配置監(jiān)控
雖然我們提到了很多的實(shí)現(xiàn)策略，現(xiàn)實(shí)實(shí)戰(zhàn)時(shí)依然容易出現(xiàn)問(wèn)題，比如不合理的操作導(dǎo)致消息丟失。
因此，我們應(yīng)該具備兜底意識(shí)。
假如少量消息丟失，我們可以通過(guò)每天凌晨跑一次任務(wù)，批量將這些未處理的訂單批量取消。這種兜底行為工程實(shí)現(xiàn)簡(jiǎn)單，同時(shí)對(duì)系統(tǒng)影響很小。
還有一點(diǎn)，就是配置監(jiān)控。
筆者曾經(jīng)自研過(guò)任務(wù)調(diào)度系統(tǒng)，應(yīng)用 A 接入后，從控制臺(tái)發(fā)現(xiàn)每隔 2 個(gè)小時(shí)調(diào)度應(yīng)用 A 的任務(wù)時(shí)，經(jīng)常發(fā)生超時(shí)，通過(guò)分析，發(fā)現(xiàn)應(yīng)用 A 線程出現(xiàn)了死鎖。
這種問(wèn)題出現(xiàn)的幾率非常高，因此配置監(jiān)控特別要必要。
對(duì)業(yè)務(wù)系統(tǒng)來(lái)講，監(jiān)控分為兩個(gè)層面：系統(tǒng)監(jiān)控和業(yè)務(wù)監(jiān)控。
- 系統(tǒng)監(jiān)控
在條件允許的情況下，建議關(guān)注性能監(jiān)控，方法可用性監(jiān)控，方法調(diào)用次數(shù)監(jiān)控這三大類(lèi)。
性能監(jiān)控
上圖是性能監(jiān)控的示例圖，性能監(jiān)控不同時(shí)間段性能分布，實(shí)時(shí)統(tǒng)計(jì) TP99、TP999 、AVG 、MAX 等維度指標(biāo)，這也是性能調(diào)優(yōu)的重點(diǎn)關(guān)注對(duì)象。
- 業(yè)務(wù)監(jiān)控
業(yè)務(wù)監(jiān)控功能是從業(yè)務(wù)角度出發(fā)，各個(gè)應(yīng)用系統(tǒng)需要從業(yè)務(wù)層面進(jìn)行哪些監(jiān)控，以及提供怎樣的業(yè)務(wù)層面的監(jiān)控功能支持業(yè)務(wù)相關(guān)的應(yīng)用系統(tǒng)。
具體就是對(duì)業(yè)務(wù)數(shù)據(jù)，業(yè)務(wù)功能進(jìn)行監(jiān)控，實(shí)時(shí)收集業(yè)務(wù)流程的數(shù)據(jù)，并根據(jù)設(shè)置的策略對(duì)業(yè)務(wù)流程中不符合預(yù)期的部分進(jìn)行預(yù)警和報(bào)警，并對(duì)收集到業(yè)務(wù)監(jiān)控?cái)?shù)據(jù)進(jìn)行集中統(tǒng)一的存儲(chǔ)和各種方式進(jìn)行展示。
比如訂單系統(tǒng)中有一個(gè)定時(shí)結(jié)算的服務(wù)，每?jī)煞昼妶?zhí)行一次。我們可以在定時(shí)任務(wù) JOB 中添加埋點(diǎn)，并配置業(yè)務(wù)監(jiān)控，假如十分鐘該定時(shí)任務(wù)沒(méi)有執(zhí)行，則發(fā)送郵件，短信給相關(guān)負(fù)責(zé)人。
6 總結(jié)
這篇文章，筆者總結(jié)了訂單超時(shí)自動(dòng)取消方案的兩種流派：定時(shí)任務(wù)和延遲消息。
1、定時(shí)任務(wù)
定時(shí)任務(wù)實(shí)現(xiàn)策略，我們可以簡(jiǎn)單劃分為單機(jī)版和集群版。
筆者并不認(rèn)可單機(jī)版，背八股文當(dāng)然可以，訂單自動(dòng)取消這個(gè)業(yè)務(wù)場(chǎng)景，生產(chǎn)環(huán)境還是要慎重。
集群版有三種方式：Quartz + JDBCJobStore、ElasticJob 、XXL-JOB 。
每種方式各有優(yōu)缺點(diǎn)，筆者更傾向于任務(wù)調(diào)度平臺(tái) XXL-JOB 這種方式。
2、延遲消息
延時(shí)消息是一種非常優(yōu)雅的模式。本文介紹了三種方式：消息隊(duì)列 RocketMQ、自研延遲服務(wù)、Redis 延遲隊(duì)列。
假如技術(shù)團(tuán)隊(duì)基礎(chǔ)架構(gòu)能力很強(qiáng)，筆者推薦使用 RocketMQ 或者自研延遲服務(wù)。
假如技術(shù)團(tuán)隊(duì)僅僅想用輕量級(jí)的實(shí)現(xiàn)，可以選擇 Redis 延遲隊(duì)列。
不管是使用定時(shí)任務(wù)還是延遲消息，架構(gòu)的穩(wěn)定性還需要注意如下兩點(diǎn)：
1、并發(fā)口訣：一鎖二判三更新 ；
2、兜底意識(shí) + 配置監(jiān)控。
