分布式定時任務框架選型，寫得太好了！

為什么我們需要定時任務

我們先思考下面幾個業(yè)務場景的解決方案:

• 支付系統(tǒng)每天凌晨1點跑批，進行一天清算，每月1號進行上個月清算
• 電商整點搶購，商品價格8點整開始優(yōu)惠
• 12306購票系統(tǒng)，超過30分鐘沒有成功支付訂單的，進行回收處理
• 商品成功發(fā)貨后，需要向客戶發(fā)送短信提醒

類似的業(yè)務場景非常多，我們怎么解決？

很多業(yè)務場景需要我們某一特定的時刻去做某件任務，定時任務解決的就是這種業(yè)務場景。一般來說，系統(tǒng)可以使用消息傳遞代替部分定時任務，兩者有很多相似之處，可以相互替換場景。

如，上面發(fā)貨成功發(fā)短信通知客戶的業(yè)務場景，我們可以在發(fā)貨成功后發(fā)送MQ消息到隊列，然后去消費mq消息，發(fā)送短信。

但在某些場景下不能互換：

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

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

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

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

有哪些定時任務的框架

單機

• timer：是一個定時器類，通過該類可以為指定的定時任務進行配置。TimerTask類是一個定時任務類，該類實現(xiàn)了Runnable接口，缺點異常未檢查會中止線程
• ScheduledExecutorService：相對延遲或者周期作為定時任務調(diào)度，缺點沒有絕對的日期或者時間
• spring定時框架：配置簡單功能較多，如果系統(tǒng)使用單機的話可以優(yōu)先考慮spring定時器

分布式

• Quartz：Java事實上的定時任務標準。但Quartz關注點在于定時任務而非數(shù)據(jù)，并無一套根據(jù)數(shù)據(jù)處理而定制化的流程。雖然Quartz可以基于數(shù)據(jù)庫實現(xiàn)作業(yè)的高可用，但缺少分布式并行調(diào)度的功能
• TBSchedule：阿里早期開源的分布式任務調(diào)度系統(tǒng)。代碼略陳舊，使用timer而非線程池執(zhí)行任務調(diào)度。眾所周知，timer在處理異常狀況時是有缺陷的。而且TBSchedule作業(yè)類型較為單一，只能是獲取/處理數(shù)據(jù)一種模式。還有就是文檔缺失比較嚴重
• elastic-job：當當開發(fā)的彈性分布式任務調(diào)度系統(tǒng)，功能豐富強大，采用zookeeper實現(xiàn)分布式協(xié)調(diào)，實現(xiàn)任務高可用以及分片，目前是版本2.15，并且可以支持云開發(fā)，這個我寫了系列教程了，在Java技術棧公從號可以搜索閱讀。
• Saturn：是唯品會自主研發(fā)的分布式的定時任務的調(diào)度平臺，基于當當?shù)膃lastic-job 版本1開發(fā)，并且可以很好的部署到docker容器上。
• xxl-job: 是大眾點評員工徐雪里于2015年發(fā)布的分布式任務調(diào)度平臺，是一個輕量級分布式任務調(diào)度框架，其核心設計目標是開發(fā)迅速、學習簡單、輕量級、易擴展。

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

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

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

X-Job　：　大眾點評公司下員工許雪里、貢獻者 3人;　github有2470star、1015fork　|　QQ討論群6個　|　有登記在使用的超過40家公司　|　文檔齊全E-Job　：　當當網(wǎng)開源，貢獻者17人;　github有2524star、1015fork　|　QQ討論群１個、源碼討論群１個　|　有登記在使用的超過50家公司　|　文檔齊全　｜　有明確的發(fā)展計劃

支持集群部署

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

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

E-Job　：　重寫Quartz基于數(shù)據(jù)庫的分布式功能，改用Zookeeper實現(xiàn)注冊中心

作業(yè)注冊中心：基于Zookeeper和其客戶端Curator實現(xiàn)的全局作業(yè)注冊控制中心。用于注冊，控制和協(xié)調(diào)分布式作業(yè)執(zhí)行。2021 最新 Java 面試題出爐！（帶全部答案）

多節(jié)點部署時任務不能重復執(zhí)行

X-Job　：　使用Quartz基于數(shù)據(jù)庫的分布式功能

E-Job　 ：　將任務拆分為n個任務項后，各個服務器分別執(zhí)行各自分配到的任務項。一旦有新的服務器加入集群，或現(xiàn)有服務器下線，elastic-job將在保留本次任務執(zhí)行不變的情況下，下次任務開始前觸發(fā)任務重分片。

日志可追溯

X-Job　：　支持，有日志查詢界面

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

監(jiān)控告警

X-Job　：　調(diào)度失敗時，將會觸發(fā)失敗報警，如發(fā)送報警郵件。

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

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

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

彈性擴容縮容

X-Job　：　使用Quartz基于數(shù)據(jù)庫的分布式功能，服務器超出一定數(shù)量會給數(shù)據(jù)庫造成一定的壓力

E-Job　：　通過zk實現(xiàn)各服務的注冊、控制及協(xié)調(diào)

支持并行調(diào)度

X-Job　：　調(diào)度系統(tǒng)多線程（默認10個線程）觸發(fā)調(diào)度運行，確保調(diào)度精確執(zhí)行，不被堵塞。

E-Job　：　采用任務分片方式實現(xiàn)。將一個任務拆分為n個獨立的任務項，由分布式的服務器并行執(zhí)行各自分配到的分片項。

高可用策略

X-Job　：　“調(diào)度中心”通過DB鎖保證集群分布式調(diào)度的一致性, 一次任務調(diào)度只會觸發(fā)一次執(zhí)行；

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

失敗處理策略

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

E-Job　：　彈性擴容縮容在下次作業(yè)運行前重分片，但本次作業(yè)執(zhí)行的過程中，下線的服務器所分配的作業(yè)將不會重新被分配。失效轉移功能可以在本次作業(yè)運行中用空閑服務器抓取孤兒作業(yè)分片執(zhí)行。同樣失效轉移功能也會犧牲部分性能。

另外，分布式系列面試題和答案全部整理好了，微信搜索Java技術棧，在后臺發(fā)送：面試，可以在線閱讀。

動態(tài)分片策略

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

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

E-Job　：　支持多種分片策略，可自定義分片策略

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

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

和quartz框架對比

• 調(diào)用API的的方式操作任務，不人性化；
• 需要持久化業(yè)務QuartzJobBean到底層數(shù)據(jù)表中，系統(tǒng)侵入性相當嚴重。
• 調(diào)度邏輯和QuartzJobBean耦合在同一個項目中，這將導致一個問題，在調(diào)度任務數(shù)量逐漸增多，同時調(diào)度任務邏輯逐漸加重的情況加，此時調(diào)度系統(tǒng)的性能將大大受限于業(yè)務；
• Quartz關注點在于定時任務而非數(shù)據(jù)，并無一套根據(jù)數(shù)據(jù)處理而定制化的流程。雖然Quartz可以基于數(shù)據(jù)庫實現(xiàn)作業(yè)的高可用，但缺少分布式并行調(diào)度的功能。

綜合對比

總結和結論

共同點：

E-Job和X-job都有廣泛的用戶基礎和完整的技術文檔，都能滿足定時任務的基本功能需求。

不同點：

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

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

附定時任務的其他方案

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

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

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

延遲和定時消息投遞

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

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