轉自https://blog.csdn.net/wylkl00/article/details/84586335
https://www.jianshu.com/p/cc2e94d92078
最近公司有要搭建一個分布式定時任務平台的需求，並把這個任務交給了我。
首先是作了一番分析了解，http://www.expectfly.com/2017/08/15/%E5%88%86%E5%B8%83%E5%BC%8F%E5%AE%9A%E6%97%B6%E4%BB%BB%E5%8A%A1%E6%96%B9%E6%A1%88%E6%8A%80%E6%9C%AF%E9%80%89%E5%9E%8B/
可以看到目前市面上常見的定時任務框架有以下這些
Quartz：Java事實上的定時任務標准。但Quartz關注點在於定時任務而非數據，並無一套根據數據處理而定制化的流程。雖然Quartz可以基於數據庫實現作業的高可用，但缺少分布式並行調度的功能
TBSchedule：阿里早期開源的分布式任務調度系統。代碼略陳舊，使用timer而非線程池執行任務調度。眾所周知，timer在處理異常狀況時是有缺陷的。而且TBSchedule作業類型較為單一，只能是獲取/處理數據一種模式。還有就是文檔缺失比較嚴重
elastic-job：當當開發的彈性分布式任務調度系統，功能豐富強大，采用zookeeper實現分布式協調，實現任務高可用以及分片，目前是版本2.15，並且可以支持雲開發
Saturn：是唯品會自主研發的分布式的定時任務的調度平台，基於當當的elastic-job 版本1開發，並且可以很好的部署到docker容器上。
xxl-job: 是大眾點評員工徐雪里於2015年發布的分布式任務調度平台，是一個輕量級分布式任務調度框架，其核心設計目標是開發迅速、學習簡單、輕量級、易擴展
可以看到最流行的就是elastic-job和xxl-job，關於這兩者理論上的對比，上述文章都有提到，可以看出來兩者都是非常優秀的定時任務平台，也都能滿足的需求，網上也有很多人在討論比較兩者的優劣。於是我就自己嘗試的一下官網的文檔和代碼分別搭了一套demo，經過實際的使用和比較之后，最終選擇了xxl-job，下面我結合上面那片文章說說我自己的理解和原因。
首先說說更新和維護情況，上面那篇文章是2017年8月寫得，到現在過了一年多在github上elastic-job似乎已經沒有在更新了，最近一個版本2.15發布於17年7月，最近一年只合並了一個pull request，而xxl-job相對來說就活躍很多最近的一個版本2.01更新與一個月以內，github上提交的代碼可以看到2.02頁即將發布。因此社區的討論的活躍程度也更高，使用的公司xxl-job也比elastic-job多了不少。之前兩者的star數差不多，現在xxl-job已經高於elastic-job兩千多了。
再來說說使用的感觸，elastic-job一開始設計的初衷就是面對高並發復雜業務的，就像網上一篇開發者舉得例子——余額寶計算收益，其核心功能在於分片和彈性擴容。尤其是在服務器數量多，業務量大的時候也能非常好的調度，壓榨服務器的性能，使用zookeeper使他具有高可用和一致性的同時有很好的可擴展性，elastic-job本身沒有中心的概念，通過zookeeper的選舉機制選舉出主服務器，任何一台服務器都可以作為主服務器，即使主服務器掛了也可以重新選舉。因此elastic-job的優勢在於它具有更好的可擴展性和可用性，但是這也使得他的使用和配置上比起xxl-job更復雜一些。
而 xxl-job的是通過一個中心式集群"調度中心”來調度多個執行器執行任務的，調度中心集群可以通過增加機器來實現高可用（HA）實際會造成一定程度上的資源浪費，調度中心通過DB鎖保證集群分布式調度的一致性，這樣擴展執行器會增大DB的壓力，但是如果實際上這里數據庫只是負責任務的調度執行。在沒有那么多數量的執行器和任務的情況下是完全沒問題的。執行器可以支持分布式部署，這實際上就足以滿足大多數場景了。關鍵是原理簡單實現也非常簡潔，用起來也很輕便，與springboot也非常好集成。而且他的監控界面直接集成到調度中心里面，可以在監控界面直接新增任務，使用GLUE模式甚至可以直接在監控界面上做任務開發寫業務代碼，這點未必用得到，但是確實很方便；而elastic-job是一個單獨的工程連到zk上去監控的，因此不能直接增新增任務，也不能停止執行中的任務。單獨記錄執行日志到數據庫，然后很方便的統一管理和重發，還有失敗的郵件提醒都是簡單又好用的功能，對於一些常規的定時任務來說感覺應該用起來很舒服。
綜合來說，xxl-job在我看來在業務量沒那么大的時候是一個更好的選擇。
這些都是hi