分布式定時任務框架選型，寫得太好了！
我們先思考下面幾個業(yè)務場景的解決方案： 為什么我們需要定時任務 java有哪些定時任務的框架 單機 分布 分布式任務調(diào)度系統(tǒng)對比 1. 什么是分布式定時任務 2. 常見開源方案 4. 比較 附 定時任務的其他方案
我們先思考下面幾個業(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è)務邏輯只能批量處理。如移動每個月結(jié)算我們的話費 c)實時性/非實時性：消息中間件能夠做到實時處理數(shù)據(jù)，但是有些情況下并不需要實時，比如：vip升級 d)系統(tǒng)內(nèi)部/系統(tǒng)解耦：定時任務調(diào)度一般是在系統(tǒng)內(nèi)部，而消息中間件可用于兩個系統(tǒng)間
java有哪些定時任務的框架
單機
timer：是一個定時器類，通過該類可以為指定的定時任務進行配置。TimerTask類是一個定時任務類，該類實現(xiàn)了Runnable接口，缺點異常未檢查會中止線程 ScheduledExecutorService：相對延遲或者周期作為定時任務調(diào)度，缺點沒有絕對的日期或者時間 spring定時框架：配置簡單功能較多，如果系統(tǒng)使用單機的話可以優(yōu)先考慮spring定時器
分布
Quartz：Java事實上的定時任務標準。但Quartz關(guān)注點在于定時任務而非數(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ā) Saturn：是唯品會自主研發(fā)的分布式的定時任務的調(diào)度平臺，基于當當?shù)膃lastic-job 版本1開發(fā)，并且可以很好的部署到docker容器上。 xxl-job: 是大眾點評員工徐雪里于2015年發(fā)布的分布式任務調(diào)度平臺，是一個輕量級分布式任務調(diào)度框架，其核心設計目標是開發(fā)迅速、學習簡單、輕量級、易擴展。
分布式任務調(diào)度系統(tǒng)對比
1. 什么是分布式定時任務
把分散的，可靠性差的計劃任務納入統(tǒng)一的平臺，并實現(xiàn)集群管理調(diào)度和分布式部署的一種定時任務的管理方式。叫做分布式定時任務。
2. 常見開源方案
elastic-job xxl-job quartz saturn opencron antares
elastic-job
elastic-job 是由當當網(wǎng)基于quartz 二次開發(fā)之后的分布式調(diào)度解決方案 ， 由兩個相對獨立的子項目Elastic-Job-Lite和Elastic-Job-Cloud組成 。
Elastic-Job-Lite定位為輕量級無中心化解決方案，使用jar包的形式提供分布式任務的協(xié)調(diào)服務。
Elastic-Job-Cloud使用Mesos + Docker(TBD)的解決方案，額外提供資源治理、應用分發(fā)以及進程隔離等服務
亮點?：
“基于quartz 定時任務框架為基礎的，因此具備quartz的大部分功能
使用zookeeper做協(xié)調(diào)，調(diào)度中心，更加輕量級
持任務的分片
支持彈性擴容 ， 可以水平擴展 ， 當任務再次運行時，會檢查當前的服務器數(shù)量，重新分片，分片結(jié)束之后才會繼續(xù)執(zhí)行任務
失效轉(zhuǎn)移，容錯處理，當一臺調(diào)度服務器宕機或者跟zookeeper斷開連接之后，會立即停止作業(yè)，然后再去尋找其他空閑的調(diào)度服務器，來運行剩余的任務
提供運維界面，可以管理作業(yè)和注冊中心。
elastic-job結(jié)合了quartz非常優(yōu)秀的時間調(diào)度功能，并且利用ZooKeeper實現(xiàn)了靈活的分片策略。除此之外，還加入了大量實用的監(jiān)控和管理功能，
以及其開源社區(qū)活躍、文檔齊全、代碼優(yōu)雅等優(yōu)點，是分布式任務調(diào)度框架的推薦選擇。
由于elastic-job-lite 不支持動態(tài)添加作業(yè)，此處僅貼上elastic-job-Cloud架構(gòu)圖
xxl-job
由個人開源的一個輕量級分布式任務調(diào)度框架 ，主要分為 調(diào)度中心和執(zhí)行器兩部分 ， 調(diào)度中心在啟動初始化的時候，會默認生成執(zhí)行器的RPC代理
對象（http協(xié)議調(diào)用）， 執(zhí)行器項目啟動之后， 調(diào)度中心在觸發(fā)定時器之后通過jobHandle 來調(diào)用執(zhí)行器項目里面的代碼，核心功能和elastic-job差不多，同時技術(shù)文檔比較完善
系統(tǒng)架構(gòu)圖?：
quartz
quartz 的常見集群方案如下，通過在數(shù)據(jù)庫中配置定時器信息， 以數(shù)據(jù)庫悲觀鎖的方式達到同一個任務始終只有一個節(jié)點在運行，
優(yōu)點?：
保證節(jié)點高可用 （HA）， 如果某一個幾點掛了， 其他節(jié)點可以頂上
缺點?：
同一個任務只能有一個節(jié)點運行，其他節(jié)點將不執(zhí)行任務，性能低，資源浪費
當碰到大量短任務時，各個節(jié)點頻繁的競爭數(shù)據(jù)庫鎖，節(jié)點越多這種情況越嚴重。性能會很低下
quartz 的分布式僅解決了集群高可用的問題，并沒有解決任務分片的問題，不能實現(xiàn)水平擴展
Saturn
Saturn是唯品會在github開源的一款分布式任務調(diào)度產(chǎn)品。它是基于當當elastic-job 1.0版本來開發(fā)的，其上完善了一些功能和添加了一些新的feature。
亮點?：
支持多語言開發(fā) python、Go、Shell、Java、Php。
管理控制臺和數(shù)據(jù)統(tǒng)計分析更加完善
缺點?：
技術(shù)文檔較少 ， 該框架是2016年由唯品會的研發(fā)團隊基于elastic-job開發(fā)而來
opencron
一個功能完善真正通用的linux定時任務調(diào)度定系統(tǒng),滿足多種場景下各種復雜的定時任務調(diào)度,同時集成了linux實時監(jiān)控,webssh,提供一個方便管理定時任務的平臺
缺點：僅支持 kill任務， 現(xiàn)場執(zhí)行，查詢?nèi)蝿者\行狀態(tài) 等， 主要功能是著重于任務的修改和查詢上。不能動態(tài)的添加任務以及任務分片。
antares
優(yōu)點?：
一個任務僅會被服務器集群中的某個節(jié)點調(diào)度，調(diào)度機制基于成熟的 quartz 并行執(zhí)行 ， 用戶可通過對任務預分片，有效提升任務執(zhí)行效率 失效轉(zhuǎn)移 彈性擴容，在任務運行時，可以動態(tài)的加機器 友好的管理控制臺
缺點?：
不能動態(tài)的添加任務，僅能在控制臺對任務進行觸發(fā)，暫停，刪除等操作 文檔不多，開源社區(qū)不夠活躍
系統(tǒng)架構(gòu)圖如下?：
4. 比較
此處列出了幾個代表性的開源產(chǎn)品
附 定時任務的其他方案
發(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。這時候消息就可以重新被消費。
關(guān)注不迷路