一篇舊文了，之前在公眾號"CurdBoys" 中發過，文章鏈接 ，現在發一下在博客園上
目前的場景是這樣的，我們組內現在有很多舊或新的定時任務都是在直接在某些服務器上跑。如果遇到要下線某台服務器，要先檢查一下這個服務器上是否還存在定時任務腳本。通常情況下，即使找到該運行的定時任務腳本，也不知道它是用來做的或者是否能遷移到其他機器上。另外，如果某台機器掛了，上面的定時任務腳本也會掛了，不能自動切換到其他機器上。
由於存在着這種情況，我們就想着把這些定時任務腳本管理起來，並且需要具備高可用。這就需要一個分布式調度任務系統。🧐
概述
關於定時執行任務的工具或框架系統有很多，一般情況下針對不同的應用場景可以選擇適合該場景下工具或框架。例如：如果不想引入其他語言，只使用shell來執行的，可以使用 linux Crontab 來執；如果是基於Spring 想着簡單實現一個定時任務，可以使用@Scheduled注解。如果按照是否為單獨的系統來分可以分為兩類：1. 系統或框架自帶的定時執行方法或工具。2. 單獨作為一個服務的調度任務系統。
系統或框架自帶的定時執行方法或工具
Linux Crontab
只能單機執行與linux機器固定綁定，可以通過cron 表達式定時執行shell腳本。簡單易使用，不好后期維護，只能執行shell腳本。
Java 原生的定時器Timer
優點：簡單，不用引入其他框架。
缺點：
- Timer在執行所有定時任務時只會創建一個線程，如果某個任務的執行時間過長，那么將破壞其他TimerTask的定時精確性
- Timer的另一個問題是，如果TimerTask拋出了一個未檢查的異常，那么Timer線程不會捕獲異常，此時會終止定時線程，並且不會恢復。
參考：java定時器之Timer使用與原理分析
Spring 的 @Scheduled注解
一般集成於項目中，小任務很方便，不能分布式。注意，如果使用了，在集群部署的時候需要使用分布式鎖來限制
單獨作為一個服務的調度任務系統
這部分主要的調度任務系統都是開源系統，並且大部分是基於Java的Quratz框架來封裝的
XXL-JOB
XXL-JOB是一個分布式任務調度平台，其核心設計目標是開發迅速、學習簡單、輕量級、易擴展。
（美團公司個人開放）“調度中心”基於集群Quartz實現，提供官方docker鏡像，作業與語言無關。社區較活躍，一直有維護狀態。 較多公司使用。
elastic-job
ElasticJob 是面向互聯網生態和海量任務的分布式調度解決方案，由兩個相互獨立的子項目 ElasticJob-Lite 和 ElasticJob-Cloud 組成。 它通過彈性調度、資源管控、以及作業治理的功能，打造一個適用於互聯網場景的分布式調度解決方案，並通過開放的架構設計，提供多元化的作業生態。 它的各個產品使用統一的作業 API，開發者僅需一次開發，即可隨意部署。
當當開源的，使用 Zookeeper 實現分布式分布式部署。2019年10月前停止維護過一段時間，后面才重新維護。並且在2020 年 5 月 28 日成為 Apache ShardingSphere 的子項目未來前景應該很不錯。
Saturn
Saturn (任務調度系統)是唯品會Venus體系的一個組成部分，負責分布式的定時任務的調度，取代傳統的Linux Cron/Spring Batch Job的方式，做到全域統一配置，統一監控，任務高可用以及分片並發處理。Saturn基於當當Elastic Job代碼基礎上自主研發的任務調度系統。
唯品會開源的，基於elastic-job。支持多種語言作業，語言無關(Java/Go/C++/PHP/Python/Ruby/shell)。社區活躍度一般，小部分公司使用。
基於Quartz自己開發
開源的有個好處就是大部分都是開箱即用。但是通常來說，如果直接使用開源的系統，后期改造起來都是比較麻煩，而且如果有什么問題，排查起來也比較麻煩，畢竟不是自己的系統。基於我們要求的調度任務系統，並不需要太多功能，所以我們計划自己基於Quartz框架來開發調度任務系統。
原生quartz任務的缺點
- 只能在單個服務器上運行，或者在多個服務器上集群運行，在單個數據庫的情況下，不能指定不同服務器運行不同任務。
為了解決原生Quartz的確定，我們基於Quartz和GRPC框架來開發任務調度系統，具體方案如下：
- 利用一台服務器部署quartz服務和作為服務注冊中心（rpc調用中心）。
- 通過創建不同的cron定時任務，通過傳入服務器地址，要執行的方法，定時遠程rpc調用不同服務器上的方法。
- 定義每個master和slaver都定義http請求調度，命令行請求調度和郵箱發送請求調度，當不需要指定執行機器時，則通過隨機找一個slaver去執行。
初版項目地址：https://github.com/KANLON/job-scheduling (這個還不太完善，目前執行還不支持執行的高可用，后面需要修改執行任務的機器為一個列表，遍歷該列表執行)
總結
如果沒有時間或資源搭一套調度任務系統，可以使用系統或框架自帶的定時執行方法或工具來簡單使用。如果需要統一管理，方便后期維護建議首先使用開源系統的。開源的分布式調度任務系統中建議使用xxl-job，該開源系統社區活躍度高，使用的公司數量相對較多，而且一直有在維護。
以下是我整理的思維導圖：
