(說明:開發中遇到需要做定時任務的需求，之前查閱了很多資料，比較雜亂，一直沒有時間做個整理。第一版用的是quartz，能滿足大部分功能，但是老大說要考慮到後期系統的健壯性和拓展性，quartz還是有很多侷限的，綜合考量下，決定用ealstic-job框架來重構，本文着重分析此框架。其中有很多內容是從其他人的博客中摘抄過來的，記不太清了，如有冒犯，請聯繫處理！)
概述
Quartz
Java上的定時任務標準。但Quartz關注點在於定時任務而非數據，並無一套根據數據處理而定製化的流程。雖然Quartz可以基於數據庫實現作業的高可用，但缺少分佈式並行調度的功能
elastic-job
噹噹開發的彈性分佈式任務調度系統，功能豐富強大，採用zookeeper實現分佈式協調，實現任務高可用以及分片，目前是版本2.1.5，並且可以支持雲開發
xxl-job
是大衆點評員工徐雪裏於2015年發佈的分佈式任務調度平臺，是一個輕量級分佈式任務調度框架，其核心設計目標是開發迅速、學習簡單、輕量級、易擴展。
對比
| 對比項 | Quartz | elastic-job | xxl-job |
|---|---|---|---|
| 依賴 | mysql | jdk1.7+，zookeeper3.4.6+，maven3.0.4+，mesos | mysql，jdk1.7+，maven3.0+ |
| 集羣、彈性擴容 | 多節點，部署，通過競爭數據庫鎖來保證只有一個節點執行任務 | 通過zookeeper的註冊與發現，可以動態的添加服務器。支持水平擴容 | 使用Quartz基於數據庫的分佈式功能，服務器超出一定數量會給數據庫造成一定的壓力 |
| 任務分片 | 不支持 | 支持 | 支持 |
| 管理界面 | 無 | 支持 | 支持 |
| 高級功能 | 無 | 彈性擴容，多種作業模式，失效轉移，運行狀態收集，多線程處理數據，冪等性，容錯處理，spring命名空間支持 | 彈性擴容，分片廣播，故障轉移，Rolling實時日誌，GLUE（支持在線編輯代碼，免發佈），任務進度監控，任務依賴，數據加密，郵件報警，運行報表，國際化 |
| 缺點 | 沒有管理界面，以及不支持任務分片等。不適用於分佈式場景 | 需要引入zookeeper，mesos，增加系統複雜度，學習成本較高 | 調度中心通過獲取DB鎖來保證集羣中執行任務的唯一性，如果短任務很多，隨着調度中心集羣數量增加，那麼數據庫的鎖競爭會比較厲害，性能不好。 |
| 任務不能重複執行 | 數據庫鎖 | 將任務拆分爲n個任務項後，各個服務器分別執行各自分配到的任務項。一旦有新的服務器加入集羣，或現有服務器下線，elastic-job將在保留本次任務執行不變的情況下，下次任務開始前觸發任重分片。 | 使用Quartz基於數據庫的分佈式功能 |
| 並行調度 | 採用任務分片方式實現。將一個任務拆分成n個獨立的任務項，由分佈式的服務器並行執行各自分配到的分片項。 | 調度系統多線程（默認10個線程）觸發調度運行，確保調度精確執行，不被堵塞。 | |
| 失敗處理策略 | 彈性擴容縮容在下次作業運行前重分片，但本次作業執行的過程中，下線的服務器所分配的作業將不會重新被分配。失效轉移功能可以在本次作業運行中用空閒服務器抓取孤兒作業分片執行。同樣失效轉移功能也會犧牲部分性能。 | 調度失敗時的處理策略，策略包括：失敗告警（默認）、失敗重試（界面可配置） | |
| 動態分片策略 | 支持多種分片策略，可自定義分片策略。 默認包含三種分片策略： 基於平均分配算法的分片策略、 作業名的哈希值奇偶數決定IP升降序算法的分片策略、根據作業名的哈希值對Job實例列表進行輪轉的分片策略，支持自定義分片策略。elastic-job的分片是通過zookeeper來實現的。分片的分片由主節點分配，如下三種情況都會觸發主節點上的分片算法執行：a、新的Job實例加入集羣b、現有的Job實例下線（如果下線的是leader節點，那麼先選舉然後觸發分片算法的執行）c、主節點選舉” | 分片廣播任務以執行器爲維度進行分片，支持動態擴容執行器集羣從而動態增加分片數量，協同進行業務處理；在進行大數據量業務操作時可顯著提升任務處理能力和速度。 執行器集羣部署時，任務路由策略選擇”分片廣播”情況下，一次任務調度將會廣播觸發對應集羣中所有執行器執行一次任務，同時傳遞分片參數；可根據分片參數開發分片任務； |
總結
quartz
- 調用API的的方式操作任務，不人性化；
- 需要持久化業務QuartzJobBean到底層數據表中，系統侵入性相當嚴重。
- 調度邏輯和QuartzJobBean耦合在同一個項目中，這將導致一個問題，在調度任務數量逐漸增多，同時調度任務邏輯逐漸加重的情況加，此時調度系統的性能將大大受限於業務；
- Quartz關注點在於定時任務而非數據，並無一套根據數據處理而定製化的流程。雖然Quartz可以基於數據庫實現作業的高可用，但缺少分佈式並行調度的功能。
xxl-job
- 側重的業務實現的簡單和管理的方便，學習成本簡單，失敗策略和路由策略豐富。推薦使用在“用戶基數相對少，服務器數量在一定範圍內”的情景下使用。
elastic-job
- 關注的是數據，增加了彈性擴容和數據分片的思路，以便於更大限度的利用分佈式服務器的資源。但是學習成本相對高些，推薦在“數據量龐大，且部署服務器數量較多”時使用。
分析elastic-job-lite框架
概述
Elastic-Job是一個分佈式調度解決方案，由兩個相互獨立的子項目Elastic-Job-Lite和Elastic-Job-Cloud組成。
Elastic-Job-Lite定位爲輕量級無中心化解決方案，使用jar包的形式提供分佈式任務的協調服務。
架構圖
![]()
作業啓動流程圖
![]()
作業執行流程圖
![]()
功能列表
- 分佈式調度協調
- 彈性擴容縮容
- 失效轉移
- 錯過執行作業重觸發
- 作業分片一致性，保證同一分片在分佈式環境中僅一個執行實例
- 自診斷並修復分佈式不穩定造成的問題
- 支持並行調度
- 支持作業生命週期操作
- 豐富的作業類型
- Spring整合以及命名空間提供
- 運維平臺
基本概念
分片概念
任務的分佈式執行，需要將一個任務拆分爲多個獨立的任務項，然後由分佈式的服務器分別執行某一個或幾個分片項。
例如：有一個遍歷數據庫某張表的作業，現有2臺服務器。爲了快速的執行作業，那麼每臺服務器應執行作業的50%。 爲滿足此需求，可將作業分成2片，每臺服務器執行1片。作業遍歷數據的邏輯應爲：服務器A遍歷ID以奇數結尾的數據；服務器B遍歷ID以偶數結尾的數據。 如果分成10片，則作業遍歷數據的邏輯應爲：每片分到的分片項應爲ID%10，而服務器A被分配到分片項0,1,2,3,4；服務器B被分配到分片項5,6,7,8,9，直接的結果就是服務器A遍歷ID以0-4結尾的數據；服務器B遍歷ID以5-9結尾的數據。
elastic-job 分片策略
shardingTotalCount:作業分片總數。
jobShardingStrategyClass:作業分片策略實現類全路徑，elasticJob提供瞭如下三種分片策略，
- AverageAllocationJobShardingStrategy :(默認的分片策略) 基於平均分配算法的分片策略。
如果有3臺服務器, 分成9片, 則每臺服務器分到的分片是: 1=[0,1,2], 2=[3,4,5], 3=[6,7,8].
如果有3臺服務器, 分成8片, 則每臺服務器分到的分片是: 1=[0,1,6], 2=[2,3,7], 3=[4,5].
如果有3臺服務器, 分成10片, 則每臺服務器分到的分片是: 1=[0,1,2,9], 2=[3,4,5], 3=[6,7,8]
- OdevitySortByNameJobShardingStrategy:根據作業名的哈希值奇偶數決定IP升降序算法的分片策略。
作業名的哈希值爲奇數則IP升序.
作業名的哈希值爲偶數則IP降序.
用於不同的作業平均分配負載至不同的服務器.
如:
1. 如果有3臺服務器, 分成2片, 作業名稱的哈希值爲奇數, 則每臺服務器分到的分片是: 1=[0], 2=[1], 3=[].
2. 如果有3臺服務器, 分成2片, 作業名稱的哈希值爲偶數, 則每臺服務器分到的分片是: 3=[0], 2=[1], 1=[].
- RotateServerByNameJobShardingStrategy:根據作業名的哈希值對服務器列表進行輪轉的分片策略。
默認使用AverageAllocationJobShardingStrategy。
shardingItemParameters:分片序列號和個性化參數對照表。
分片序列號和參數用等號分隔, 多個鍵值對用逗號分隔。
分片序列號從0開始, 不可大於或等於作業分片總數。
分片的維度通常有狀態(state)、類型(accountType)、id分區等，需要按照業務合適選取。
分片項與業務處理解耦
Elastic-Job並不直接提供數據處理的功能，框架只會將分片項分配至各個運行中的作業服務器，開發者需要自行處理分片項與真實數據的對應關係。
個性化參數的適用場景
個性化參數即shardingItemParameter，可以和分片項匹配對應關係，用於將分片項的數字轉換爲更加可讀的業務代碼。
例如：按照地區水平拆分數據庫，數據庫A是北京的數據；數據庫B是上海的數據；數據庫C是廣州的數據。 如果僅按照分片項配置，開發者需要了解0表示北京；1表示上海；2表示廣州。 合理使用個性化參數可以讓代碼更可讀，如果配置爲0=北京,1=上海,2=廣州，那麼代碼中直接使用北京，上海，廣州的枚舉值即可完成分片項和業務邏輯的對應關係。
核心理念
分佈式調度
Elastic-Job-Lite並無作業調度中心節點，而是基於部署作業框架的程序在到達相應時間點時各自觸發調度。
註冊中心僅用於作業註冊和監控信息存儲。而主作業節點僅用於處理分片和清理等功能。
作業高可用
Elastic-Job-Lite提供最安全的方式執行作業。將分片總數設置爲1，並使用多於1臺的服務器執行作業，作業將會以1主n從的方式執行。
一旦執行作業的服務器崩潰，等待執行的服務器將會在下次作業啓動時替補執行。開啓失效轉移功能效果更好，可以保證在本次作業執行時崩潰，備機立即啓動替補執行。
最大限度利用資源
Elastic-Job-Lite也提供最靈活的方式，最大限度的提高執行作業的吞吐量。將分片項設置爲大於服務器的數量，最好是大於服務器倍數的數量，作業將會合理的利用分佈式資源，動態的分配分片項。
