分布式定時任務(wù)框架選型,寫得太好了!
AI全套:Python3+TensorFlow打造人臉識別智能小程序
最新人工智能資料-Google工程師親授 Tensorflow-入門到進階
黑馬頭條項目 - Java Springboot2.0(視頻、資料、代碼和講義)14天完整版
來源:expectfly.com/分布式定時任務(wù)方案技術(shù)選型/
1. 前言
我們先思考下面幾個業(yè)務(wù)場景的解決方案:
支付系統(tǒng)每天凌晨1點跑批,進行一天清算,每月1號進行上個月清算 電商整點搶購,商品價格8點整開始優(yōu)惠 12306購票系統(tǒng),超過30分鐘沒有成功支付訂單的,進行回收處理 商品成功發(fā)貨后,需要向客戶發(fā)送短信提醒
“”
如,上面發(fā)貨成功發(fā)短信通知客戶的業(yè)務(wù)場景,我們可以在發(fā)貨成功后發(fā)送MQ消息到隊列,然后去消費mq消息,發(fā)送短信。
時間驅(qū)動/事件驅(qū)動:內(nèi)部系統(tǒng)一般可以通過時間來驅(qū)動,但涉及到外部系統(tǒng),則只能使用時間驅(qū)動。如怕取外部網(wǎng)站價格,每小時爬一次
實時性/非實時性:消息中間件能夠做到實時處理數(shù)據(jù),但是有些情況下并不需要實時,比如:vip升級
系統(tǒng)內(nèi)部/系統(tǒng)解耦:定時任務(wù)調(diào)度一般是在系統(tǒng)內(nèi)部,而消息中間件可用于兩個系統(tǒng)間
2. 定時任務(wù)框架
單機
timer:是一個定時器類,通過該類可以為指定的定時任務(wù)進行配置。TimerTask類是一個定時任務(wù)類,該類實現(xiàn)了Runnable接口,缺點異常未檢查會中止線程 ScheduledExecutorService:相對延遲或者周期作為定時任務(wù)調(diào)度,缺點沒有絕對的日期或者時間 spring定時框架:配置簡單功能較多,如果系統(tǒng)使用單機的話可以優(yōu)先考慮spring定時器
分布式
Quartz:Java事實上的定時任務(wù)標準。但Quartz關(guān)注點在于定時任務(wù)而非數(shù)據(jù),并無一套根據(jù)數(shù)據(jù)處理而定制化的流程。雖然Quartz可以基于數(shù)據(jù)庫實現(xiàn)作業(yè)的高可用,但缺少分布式并行調(diào)度的功能
TBSchedule:阿里早期開源的分布式任務(wù)調(diào)度系統(tǒng)。代碼略陳舊,使用timer而非線程池執(zhí)行任務(wù)調(diào)度。眾所周知,timer在處理異常狀況時是有缺陷的。而且TBSchedule作業(yè)類型較為單一,只能是獲取/處理數(shù)據(jù)一種模式。還有就是文檔缺失比較嚴重
elastic-job:當(dāng)當(dāng)開發(fā)的彈性分布式任務(wù)調(diào)度系統(tǒng),功能豐富強大,采用zookeeper實現(xiàn)分布式協(xié)調(diào),實現(xiàn)任務(wù)高可用以及分片,目前是版本2.15,并且可以支持云開發(fā),這個我寫了系列教程了,在互聯(lián)網(wǎng)架構(gòu)師公從號可以搜索閱讀。
Saturn:是唯品會自主研發(fā)的分布式的定時任務(wù)的調(diào)度平臺,基于當(dāng)當(dāng)?shù)膃lastic-job 版本1開發(fā),并且可以很好的部署到docker容器上。
3. 分布式任務(wù)調(diào)度系統(tǒng)對比
參與對比的可選系統(tǒng)方案:elastic——job (以下簡稱E-Job)與 xxx-job(以下簡稱X-Job)
X-Job:
大眾點評公司下員工許雪里、貢獻者 3人;
github有2470star、1015fork;
QQ討論群6個;
有登記在使用的超過40家公司;
文檔齊全
E-Job:
當(dāng)當(dāng)網(wǎng)開源,貢獻者17人;
github有2524star、1015fork;
QQ討論群1個、源碼討論群1個;
有登記在使用的超過50家公司;
文檔齊全;
有明確的發(fā)展計劃
X-Job:集群部署唯一要求為:保證每個集群節(jié)點配置(db和登陸賬號等)保持一致。調(diào)度中心通過db配置區(qū)分不同集群。
E-Job:重寫Quartz基于數(shù)據(jù)庫的分布式功能,改用Zookeeper實現(xiàn)注冊中心
作業(yè)注冊中心:基于Zookeeper和其客戶端Curator實現(xiàn)的全局作業(yè)注冊控制中心。用于注冊,控制和協(xié)調(diào)分布式作業(yè)執(zhí)行。
多節(jié)點部署時任務(wù)不能重復(fù)執(zhí)行
X-Job:使用Quartz基于數(shù)據(jù)庫的分布式功能
監(jiān)控告警
X-Job:調(diào)度失敗時,將會觸發(fā)失敗報警,如發(fā)送報警郵件。
任務(wù)調(diào)度失敗時郵件通知的郵箱地址,支持配置多郵箱地址,配置多個郵箱地址時用逗號分隔
E-Job:通過事件訂閱方式可自行實現(xiàn)
彈性擴容縮容
X-Job:使用Quartz基于數(shù)據(jù)庫的分布式功能,服務(wù)器超出一定數(shù)量會給數(shù)據(jù)庫造成一定的壓力
搜索公眾號互聯(lián)網(wǎng)架構(gòu)師后臺回復(fù)“2T”,獲取一份驚喜禮包。
E-Job:通過zk實現(xiàn)各服務(wù)的注冊、控制及協(xié)調(diào)
支持并行調(diào)度
X-Job:調(diào)度系統(tǒng)多線程(默認10個線程)觸發(fā)調(diào)度運行,確保調(diào)度精確執(zhí)行,不被堵塞。
E-Job:采用任務(wù)分片方式實現(xiàn)。將一個任務(wù)拆分為n個獨立的任務(wù)項,由分布式的服務(wù)器并行執(zhí)行各自分配到的分片項。
X-Job:“調(diào)度中心”通過DB鎖保證集群分布式調(diào)度的一致性, 一次任務(wù)調(diào)度只會觸發(fā)一次執(zhí)行;
失敗處理策略
X-Job:調(diào)度失敗時的處理策略,策略包括:失敗告警(默認)、失敗重試;
動態(tài)分片策略
執(zhí)行器集群部署時,任務(wù)路由策略選擇”分片廣播”情況下,一次任務(wù)調(diào)度將會廣播觸發(fā)對應(yīng)集群中所有執(zhí)行器執(zhí)行一次任務(wù),同時傳遞分片參數(shù);可根據(jù)分片參數(shù)開發(fā)分片任務(wù);
4. 和quartz框架對比
5. 綜合對比

6. 總結(jié)和結(jié)論
共同點:
E-Job和X-job都有廣泛的用戶基礎(chǔ)和完整的技術(shù)文檔,都能滿足定時任務(wù)的基本功能需求。
7. 附定時任務(wù)的其他方案
發(fā)貨后超過10天未收貨時系統(tǒng)自動確認收貨的多種實現(xiàn)方式:
每天定時半夜篩選第二天 可以自動確認收貨的訂單,然后第二天 每10分鐘 執(zhí)行一次確認收貨 開銷不會太大吧 時間也相對精確 自動確認收貨這個狀態(tài)如果僅僅是讓客戶端看的話,等用戶下一次上線的時間,做一次運算就可以了。 延遲和定時消息投遞 ActiveMQ提供了一種broker端消息定時調(diào)度機制。適用于:1、不希望消息馬上被broker投遞出去,而是想要消息60秒以后發(fā)給消費者,2、想讓消息沒隔一定時間投遞一次,一共投遞指定的次數(shù) RabbitMQ可以針對Queue和Message設(shè)置 x-message-tt,來控制消息的生存時間,如果超時,則消息變?yōu)閐ead letter。利用DLX,當(dāng)消息在一個隊列中變成死信后,它能被重新publish到另一個Exchange。這時候消息就可以重新被消費。
好了,今天就分享到這里。希望對你有所幫助!
全棧架構(gòu)社區(qū)交流群
?「全棧架構(gòu)社區(qū)」建立了讀者架構(gòu)師交流群,大家可以添加小編微信進行加群。歡迎有想法、樂于分享的朋友們一起交流學(xué)習(xí)。
看完本文有收獲?請轉(zhuǎn)發(fā)分享給更多人
往期資源:
