最近有對分佈式任務調度框架的選型，下面是個人整理的一個比較文檔，供大家參考使用。分佈式任務調度框架各有利弊，需根據實際需求決定使用。
| 框架名稱 | xxl-job | elastic-job |
| 簡介 | 大衆點評員工徐雪裏於2015年發佈的分佈式任務調度平臺，是一個輕量級分佈式任務調度框架，其核心設計目標是開發迅速、學習簡單、輕量級、易擴展。 | 噹噹開發的彈性分佈式任務調度系統，功能豐富強大，採用zookeeper實現分佈式協調，實現任務高可用以及分片，並且可以支持雲開發，由兩個相互獨立的子項目Elastic-Job-Lite和Elastic-Job-Cloud組成。 |
| 社區力量 | 大衆點評公司下員工許雪裏、貢獻者16人，官網登記使用公司有133家 | 噹噹網開源，貢獻者29人，官網公佈使用公司有46家 |
| 鏈接 | http://www.xuxueli.com/xxl-job/#/ | http://elasticjob.io/index_zh.html |
| 文檔 | 完善 | 完善 |
| 集羣部署 | 執行器支持集羣部署，提升調度系統可用性，同時提升任務處理能力。集羣部署唯一要求爲：保證集羣中每個執行器的配置項 “xxl.job.admin.addresses/調度中心地址” 保持一致，執行器根據該配置進行執行器自動註冊等操作 | 作業註冊中心： 基於Zookeeper和其客戶端Curator實現的全局作業註冊控制中心。用於註冊，控制和協調分佈式作業執行 |
| 多節點任務執行 | 使用Quartz基於數據庫的分佈式功能避免重複執行任務 | 將任務拆分爲n個任務項後，各個服務器分別執行各自分配到的任務項。一旦有新的服務器加入集羣，或現有服務器下線，elastic-job將在保留本次任務執行不變的情況下，下次任務開始前觸發任務重分片 |
| 日誌跟蹤 | 支持，有日誌查詢界面 | 可通過事件訂閱的方式處理調度過程的重要事件，用於查詢、統計和監控。Elastic-Job目前提供了基於關係型數據庫兩種事件訂閱方式記錄事件 |
| 監控告警 | 任務調度失敗時郵件通知的郵箱地址，支持配置多郵箱地址，配置多個郵箱地址時用逗號分隔 | 通過事件訂閱方式可自行實現 |
| 彈性擴容縮容 | 使用Quartz基於數據庫的分佈式功能，服務器超出一定數量會給數據庫造成一定的壓力 | 通過zk實現各服務的註冊、控制及協調 |
| 並行調度 | 調度系統多線程（默認10個線程）觸發調度運行，確保調度精確執行，不被堵塞 | 採用任務分片方式實現。將一個任務拆分爲n個獨立的任務項，由分佈式的服務器並行執行各自分配到的分片項 |
| 高可用策略 | “調度中心”通過DB鎖保證集羣分佈式調度的一致性, 一次任務調度只會觸發一次執行 | 調度器的高可用是通過運行幾個指向同一個ZooKeeper集羣的Elastic-Job-Cloud-Scheduler實例來實現的。ZooKeeper用於在當前主Elastic-Job-Cloud-Scheduler實例失敗的情況下執行領導者選舉。通過至少兩個調度器實例來構成集羣，集羣中只有一個調度器實例提供服務，其他實例處於”待命”狀態。當該實例失敗時，集羣會選舉剩餘實例中的一個來繼續提供服務 |
| 失敗處理策略 | 調度失敗時的處理策略，策略包括：失敗告警（默認）、失敗重試 | 彈性擴容縮容在下次作業運行前重分片，但本次作業執行的過程中，下線的服務器所分配的作業將不會重新被分配。失效轉移功能可以在本次作業運行中用空閒服務器抓取孤兒作業分片執行。同樣失效轉移功能也會犧牲部分性能 |
| 難易程度 | 簡單 | 較複雜，需要深入理解分片原理算法 |
| 動態分片策略 | 分片廣播任務以執行器爲維度進行分片，支持動態擴容執行器集羣從而動態增加分片數量，協同進行業務處理；在進行大數據量業務操作時可顯著提升任務處理能力和速度(執行器集羣部署時，任務路由策略選擇”分片廣播”情況下，一次任務調度將會廣播觸發對應集羣中所有執行器執行一次任務，同時傳遞分片參數；可根據分片參數開發分片任務) | 默認包含三種分片策略： 基於平均分配算法的分片策略、 作業名的哈希值奇偶數決定IP升降序算法的分片策略、根據作業名的哈希值對Job實例列表進行輪轉的分片策略，支持自定義分片策略。elastic-job的分片是通過zookeeper來實現的。分片的分片由主節點分配，如下三種情況都會觸發主節點上的分片算法執行： a、新的Job實例加入集羣 b、現有的Job實例下線（如果下線的是leader節點，那麼先選舉然後觸發分片算法的執行） c、主節點選舉” |
| 側重點 | 側重的業務實現的簡單和管理的方便，學習成本簡單，失敗策略和路由策略豐富。推薦使用在“用戶基數相對少，服務器數量在一定範圍內”的情景下使用 | 關注的是數據，增加了彈性擴容和數據分片的思路，以便於更大限度的利用分佈式服務器的資源。但是學習成本相對高些，推薦在“數據量龐大，且部署服務器數量較多”時使用 |
| 對比Quartz | 1.調用API的的方式操作任務，不人性化； 2.需要持久化業務QuartzJobBean到底層數據表中，系統侵入性相當嚴重。 3.調度邏輯和QuartzJobBean耦合在同一個項目中，這將導致一個問題，在調度任務數量逐漸增多，同時調度任務邏輯逐漸加重的情況加，此時調度系統的性能將大大受限於業務； 4.Quartz關注點在於定時任務而非數據，並無一套根據數據處理而定製化的流程。雖然Quartz可以基於數據庫實現作業的高可用，但缺少分佈式並行調度的功能。 |
阿里開源的TBSchedule：https://blog.csdn.net/wwd0501/article/details/85245313
文章來源：http://www.manongjc.com/article/109455.html
https://blog.csdn.net/u_ascend/article/details/86633045