我們先思考下面幾個(gè)業(yè)務(wù)場(chǎng)景的解決方案:

支付系統(tǒng)每天凌晨1點(diǎn)跑批，進(jìn)行一天清算，每月1號(hào)進(jìn)行上個(gè)月清算

電商整點(diǎn)搶購，商品價(jià)格8點(diǎn)整開始優(yōu)惠

12306購票系統(tǒng)，超過30分鐘沒有成功支付訂單的，進(jìn)行回收處理

商品成功發(fā)貨后，需要向客戶發(fā)送短信提醒

類似的業(yè)務(wù)場(chǎng)景非常多，我們?cè)趺唇鉀Q？

為什么我們需要定時(shí)任務(wù)

很多業(yè)務(wù)場(chǎng)景需要我們某一特定的時(shí)刻去做某件任務(wù)，定時(shí)任務(wù)解決的就是這種業(yè)務(wù)場(chǎng)景。一般來說，系統(tǒng)可以使用消息傳遞代替部分定時(shí)任務(wù)，兩者有很多相似之處，可以相互替換場(chǎng)景。如，上面發(fā)貨成功發(fā)短信通知客戶的業(yè)務(wù)場(chǎng)景，我們可以在發(fā)貨成功后發(fā)送MQ消息到隊(duì)列，然后去消費(fèi)mq消息，發(fā)送短信。但在某些場(chǎng)景下不能互換：

a)時(shí)間驅(qū)動(dòng)/事件驅(qū)動(dòng)：內(nèi)部系統(tǒng)一般可以通過時(shí)間來驅(qū)動(dòng)，但涉及到外部系統(tǒng)，則只能使用時(shí)間驅(qū)動(dòng)。如怕取外部網(wǎng)站價(jià)格，每小時(shí)爬一次

b)批量處理/逐條處理：批量處理堆積的數(shù)據(jù)更加高效，在不需要實(shí)時(shí)性的情況下比消息中間件更有優(yōu)勢(shì)。而且有的業(yè)務(wù)邏輯只能批量處理。如移動(dòng)每個(gè)月結(jié)算我們的話費(fèi)

c)實(shí)時(shí)性/非實(shí)時(shí)性：消息中間件能夠做到實(shí)時(shí)處理數(shù)據(jù)，但是有些情況下并不需要實(shí)時(shí)，比如：vip升級(jí)

d)系統(tǒng)內(nèi)部/系統(tǒng)解耦：定時(shí)任務(wù)調(diào)度一般是在系統(tǒng)內(nèi)部，而消息中間件可用于兩個(gè)系統(tǒng)間

基于 Spring Boot + MyBatis Plus + Vue & Element 實(shí)現(xiàn)的后臺(tái)管理系統(tǒng) + 用戶小程序，支持 RBAC 動(dòng)態(tài)權(quán)限、多租戶、數(shù)據(jù)權(quán)限、工作流、三方登錄、支付、短信、商城等功能

項(xiàng)目地址：https://github.com/YunaiV/ruoyi-vue-pro

視頻教程：https://doc.iocoder.cn/video/

java有哪些定時(shí)任務(wù)的框架

單機(jī)

timer：是一個(gè)定時(shí)器類，通過該類可以為指定的定時(shí)任務(wù)進(jìn)行配置。TimerTask類是一個(gè)定時(shí)任務(wù)類，該類實(shí)現(xiàn)了Runnable接口，缺點(diǎn)異常未檢查會(huì)中止線程

ScheduledExecutorService：相對(duì)延遲或者周期作為定時(shí)任務(wù)調(diào)度，缺點(diǎn)沒有絕對(duì)的日期或者時(shí)間

spring定時(shí)框架：配置簡(jiǎn)單功能較多，如果系統(tǒng)使用單機(jī)的話可以優(yōu)先考慮spring定時(shí)器

分布

Quartz：Java事實(shí)上的定時(shí)任務(wù)標(biāo)準(zhǔn)。但Quartz關(guān)注點(diǎn)在于定時(shí)任務(wù)而非數(shù)據(jù)，并無一套根據(jù)數(shù)據(jù)處理而定制化的流程。雖然Quartz可以基于數(shù)據(jù)庫實(shí)現(xiàn)作業(yè)的高可用，但缺少分布式并行調(diào)度的功能

TBSchedule：阿里早期開源的分布式任務(wù)調(diào)度系統(tǒng)。代碼略陳舊，使用timer而非線程池執(zhí)行任務(wù)調(diào)度。眾所周知，timer在處理異常狀況時(shí)是有缺陷的。而且TBSchedule作業(yè)類型較為單一，只能是獲取/處理數(shù)據(jù)一種模式。還有就是文檔缺失比較嚴(yán)重

elastic-job：當(dāng)當(dāng)開發(fā)的彈性分布式任務(wù)調(diào)度系統(tǒng)，功能豐富強(qiáng)大，采用zookeeper實(shí)現(xiàn)分布式協(xié)調(diào)，實(shí)現(xiàn)任務(wù)高可用以及分片，目前是版本2.15，并且可以支持云開發(fā)

Saturn：是唯品會(huì)自主研發(fā)的分布式的定時(shí)任務(wù)的調(diào)度平臺(tái)，基于當(dāng)當(dāng)?shù)膃lastic-job 版本1開發(fā)，并且可以很好的部署到docker容器上。

xxl-job: 是大眾點(diǎn)評(píng)員工徐雪里于2015年發(fā)布的分布式任務(wù)調(diào)度平臺(tái)，是一個(gè)輕量級(jí)分布式任務(wù)調(diào)度框架，其核心設(shè)計(jì)目標(biāo)是開發(fā)迅速、學(xué)習(xí)簡(jiǎn)單、輕量級(jí)、易擴(kuò)展。

基于 Spring Cloud Alibaba + Gateway + Nacos + RocketMQ + Vue & Element 實(shí)現(xiàn)的后臺(tái)管理系統(tǒng) + 用戶小程序，支持 RBAC 動(dòng)態(tài)權(quán)限、多租戶、數(shù)據(jù)權(quán)限、工作流、三方登錄、支付、短信、商城等功能

項(xiàng)目地址：https://github.com/YunaiV/yudao-cloud

視頻教程：https://doc.iocoder.cn/video/

分布式任務(wù)調(diào)度系統(tǒng)對(duì)比

參與對(duì)比的可選系統(tǒng)方案： elastic——job （以下簡(jiǎn)稱E-Job）與 xxx-job(以下簡(jiǎn)稱X-Job)

項(xiàng)目背景及社區(qū)力量

X-Job?。骸〈蟊婞c(diǎn)評(píng)公司下員工許雪里、貢獻(xiàn)者 3人;　github有2470star、1015fork　|　QQ討論群6個(gè)　|　有登記在使用的超過40家公司　|　文檔齊全

E-Job　：　當(dāng)當(dāng)網(wǎng)開源，貢獻(xiàn)者17人;　github有2524star、1015fork　|　QQ討論群１個(gè)、源碼討論群１個(gè)　|　有登記在使用的超過50家公司　|　文檔齊全　｜　有明確的發(fā)展計(jì)劃

支持集群部署

X-Job　：　集群部署唯一要求為：保證每個(gè)集群節(jié)點(diǎn)配置（db和登陸賬號(hào)等）保持一致。調(diào)度中心通過db配置區(qū)分不同集群。

執(zhí)行器支持集群部署，提升調(diào)度系統(tǒng)可用性，同時(shí)提升任務(wù)處理能力。集群部署唯一要求為：保證集群中每個(gè)執(zhí)行器的配置項(xiàng) “xxl.job.admin.addresses/調(diào)度中心地址” 保持一致，執(zhí)行器根據(jù)該配置進(jìn)行執(zhí)行器自動(dòng)注冊(cè)等操作。

E-Job?。骸≈貙慟uartz基于數(shù)據(jù)庫的分布式功能，改用Zookeeper實(shí)現(xiàn)注冊(cè)中心

作業(yè)注冊(cè)中心： 基于Zookeeper和其客戶端Curator實(shí)現(xiàn)的全局作業(yè)注冊(cè)控制中心。用于注冊(cè)，控制和協(xié)調(diào)分布式作業(yè)執(zhí)行。

多節(jié)點(diǎn)部署時(shí)任務(wù)不能重復(fù)執(zhí)行

X-Job　：　使用Quartz基于數(shù)據(jù)庫的分布式功能E-Job　 ：　將任務(wù)拆分為n個(gè)任務(wù)項(xiàng)后，各個(gè)服務(wù)器分別執(zhí)行各自分配到的任務(wù)項(xiàng)。一旦有新的服務(wù)器加入集群，或現(xiàn)有服務(wù)器下線，elastic-job將在保留本次任務(wù)執(zhí)行不變的情況下，下次任務(wù)開始前觸發(fā)任務(wù)重分片。

日志可追溯

X-Job?。骸≈С郑腥罩静樵兘缑?/p>

E-Job?。骸】赏ㄟ^事件訂閱的方式處理調(diào)度過程的重要事件，用于查詢、統(tǒng)計(jì)和監(jiān)控。Elastic-Job目前提供了基于關(guān)系型數(shù)據(jù)庫兩種事件訂閱方式記錄事件。

監(jiān)控告警

X-Job?。骸≌{(diào)度失敗時(shí)，將會(huì)觸發(fā)失敗報(bào)警，如發(fā)送報(bào)警郵件。

任務(wù)調(diào)度失敗時(shí)郵件通知的郵箱地址，支持配置多郵箱地址，配置多個(gè)郵箱地址時(shí)用逗號(hào)分隔

E-Job　：　通過事件訂閱方式可自行實(shí)現(xiàn)

作業(yè)運(yùn)行狀態(tài)監(jiān)控、監(jiān)聽作業(yè)服務(wù)器存活、監(jiān)聽近期數(shù)據(jù)處理成功、數(shù)據(jù)流類型作業(yè)（可通過監(jiān)聽近期數(shù)據(jù)處理成功數(shù)判斷作業(yè)流量是否正常,如果小于作業(yè)正常處理的閥值，可選擇報(bào)警。）、監(jiān)聽近期數(shù)據(jù)處理失?。赏ㄟ^監(jiān)聽近期數(shù)據(jù)處理失敗數(shù)判斷作業(yè)處理結(jié)果，如果大于0，可選擇報(bào)警。）

彈性擴(kuò)容縮容

X-Job?。骸∈褂肣uartz基于數(shù)據(jù)庫的分布式功能，服務(wù)器超出一定數(shù)量會(huì)給數(shù)據(jù)庫造成一定的壓力

E-Job?。骸⊥ㄟ^zk實(shí)現(xiàn)各服務(wù)的注冊(cè)、控制及協(xié)調(diào)

支持并行調(diào)度

X-Job?。骸≌{(diào)度系統(tǒng)多線程（默認(rèn)10個(gè)線程）觸發(fā)調(diào)度運(yùn)行，確保調(diào)度精確執(zhí)行，不被堵塞。E-Job?。骸〔捎萌蝿?wù)分片方式實(shí)現(xiàn)。將一個(gè)任務(wù)拆分為n個(gè)獨(dú)立的任務(wù)項(xiàng)，由分布式的服務(wù)器并行執(zhí)行各自分配到的分片項(xiàng)。

高可用策略

X-Job?。骸　罢{(diào)度中心”通過DB鎖保證集群分布式調(diào)度的一致性, 一次任務(wù)調(diào)度只會(huì)觸發(fā)一次執(zhí)行；

E-Job　：　調(diào)度器的高可用是通過運(yùn)行幾個(gè)指向同一個(gè)ZooKeeper集群的Elastic-Job-Cloud-Scheduler實(shí)例來實(shí)現(xiàn)的。ZooKeeper用于在當(dāng)前主Elastic-Job-Cloud-Scheduler實(shí)例失敗的情況下執(zhí)行領(lǐng)導(dǎo)者選舉。通過至少兩個(gè)調(diào)度器實(shí)例來構(gòu)成集群，集群中只有一個(gè)調(diào)度器實(shí)例提供服務(wù)，其他實(shí)例處于”待命”狀態(tài)。當(dāng)該實(shí)例失敗時(shí)，集群會(huì)選舉剩余實(shí)例中的一個(gè)來繼續(xù)提供服務(wù)。

失敗處理策略

X-Job　：　調(diào)度失敗時(shí)的處理策略，策略包括：失敗告警（默認(rèn)）、失敗重試；

E-Job?。骸椥詳U(kuò)容縮容在下次作業(yè)運(yùn)行前重分片，但本次作業(yè)執(zhí)行的過程中，下線的服務(wù)器所分配的作業(yè)將不會(huì)重新被分配。失效轉(zhuǎn)移功能可以在本次作業(yè)運(yùn)行中用空閑服務(wù)器抓取孤兒作業(yè)分片執(zhí)行。同樣失效轉(zhuǎn)移功能也會(huì)犧牲部分性能。

動(dòng)態(tài)分片策略

X-Job?。骸》制瑥V播任務(wù)以執(zhí)行器為維度進(jìn)行分片，支持動(dòng)態(tài)擴(kuò)容執(zhí)行器集群從而動(dòng)態(tài)增加分片數(shù)量，協(xié)同進(jìn)行業(yè)務(wù)處理；在進(jìn)行大數(shù)據(jù)量業(yè)務(wù)操作時(shí)可顯著提升任務(wù)處理能力和速度。

執(zhí)行器集群部署時(shí)，任務(wù)路由策略選擇”分片廣播”情況下，一次任務(wù)調(diào)度將會(huì)廣播觸發(fā)對(duì)應(yīng)集群中所有執(zhí)行器執(zhí)行一次任務(wù)，同時(shí)傳遞分片參數(shù)；可根據(jù)分片參數(shù)開發(fā)分片任務(wù)；

E-Job?。骸≈С侄喾N分片策略，可自定義分片策略

默認(rèn)包含三種分片策略： 基于平均分配算法的分片策略、 作業(yè)名的哈希值奇偶數(shù)決定IP升降序算法的分片策略、根據(jù)作業(yè)名的哈希值對(duì)Job實(shí)例列表進(jìn)行輪轉(zhuǎn)的分片策略，支持自定義分片策略

elastic-job的分片是通過zookeeper來實(shí)現(xiàn)的。分片的分片由主節(jié)點(diǎn)分配，如下三種情況都會(huì)觸發(fā)主節(jié)點(diǎn)上的分片算法執(zhí)行：a、新的Job實(shí)例加入集群b、現(xiàn)有的Job實(shí)例下線（如果下線的是leader節(jié)點(diǎn)，那么先選舉然后觸發(fā)分片算法的執(zhí)行）c、主節(jié)點(diǎn)選舉”

和quartz框架對(duì)比

調(diào)用API的的方式操作任務(wù)，不人性化；

需要持久化業(yè)務(wù)QuartzJobBean到底層數(shù)據(jù)表中，系統(tǒng)侵入性相當(dāng)嚴(yán)重。

調(diào)度邏輯和QuartzJobBean耦合在同一個(gè)項(xiàng)目中，這將導(dǎo)致一個(gè)問題，在調(diào)度任務(wù)數(shù)量逐漸增多，同時(shí)調(diào)度任務(wù)邏輯逐漸加重的情況加，此時(shí)調(diào)度系統(tǒng)的性能將大大受限于業(yè)務(wù)；

Quartz關(guān)注點(diǎn)在于定時(shí)任務(wù)而非數(shù)據(jù)，并無一套根據(jù)數(shù)據(jù)處理而定制化的流程。雖然Quartz可以基于數(shù)據(jù)庫實(shí)現(xiàn)作業(yè)的高可用，但缺少分布式并行調(diào)度的功能。

綜合對(duì)比

總結(jié)和結(jié)論

共同點(diǎn)： E-Job和X-job都有廣泛的用戶基礎(chǔ)和完整的技術(shù)文檔，都能滿足定時(shí)任務(wù)的基本功能需求。

不同點(diǎn)

X-Job 側(cè)重的業(yè)務(wù)實(shí)現(xiàn)的簡(jiǎn)單和管理的方便，學(xué)習(xí)成本簡(jiǎn)單，失敗策略和路由策略豐富。推薦使用在“用戶基數(shù)相對(duì)少，服務(wù)器數(shù)量在一定范圍內(nèi)”的情景下使用

E-Job 關(guān)注的是數(shù)據(jù)，增加了彈性擴(kuò)容和數(shù)據(jù)分片的思路，以便于更大限度的利用分布式服務(wù)器的資源。但是學(xué)習(xí)成本相對(duì)高些，推薦在“數(shù)據(jù)量龐大，且部署服務(wù)器數(shù)量較多”時(shí)使用

附 定時(shí)任務(wù)的其他方案

發(fā)貨后超過10天未收貨時(shí)系統(tǒng)自動(dòng)確認(rèn)收貨的多種實(shí)現(xiàn)方式

每天定時(shí)半夜篩選第二天 可以自動(dòng)確認(rèn)收貨的訂單,然后第二天 每10分鐘 執(zhí)行一次確認(rèn)收貨 開銷不會(huì)太大吧 時(shí)間也相對(duì)精確

自動(dòng)確認(rèn)收貨這個(gè)狀態(tài)如果僅僅是讓客戶端看的話，等用戶下一次上線的時(shí)間，做一次運(yùn)算就可以了。

延遲和定時(shí)消息投遞ActiveMQ提供了一種broker端消息定時(shí)調(diào)度機(jī)制。適用于：1、不希望消息馬上被broker投遞出去，而是想要消息60秒以后發(fā)給消費(fèi)者，2、想讓消息沒隔一定時(shí)間投遞一次，一共投遞指定的次數(shù)

RabbitMQ可以針對(duì)Queue和Message設(shè)置 x-message-tt，來控制消息的生存時(shí)間，如果超時(shí)，則消息變?yōu)閐ead letter。利用DLX，當(dāng)消息在一個(gè)隊(duì)列中變成死信后，它能被重新publish到另一個(gè)Exchange。這時(shí)候消息就可以重新被消費(fèi)。

編輯：黃飛

?