分佈式調度任務系統調研及選型

一篇舊文了，以前在公衆號"CurdBoys" 中發過，文章連接 ，如今發一下在博客園上

目前的場景是這樣的，咱們組內如今有不少舊或新的定時任務都是在直接在某些服務器上跑。若是遇到要下線某臺服務器，要先檢查一下這個服務器上是否還存在定時任務腳本。一般狀況下，即便找到該運行的定時任務腳本，也不知道它是用來作的或者是否能遷移到其餘機器上。另外，若是某臺機器掛了，上面的定時任務腳本也會掛了，不能自動切換到其餘機器上。

因爲存在着這種狀況，咱們就想着把這些定時任務腳本管理起來，而且須要具有高可用。這就須要一個分佈式調度任務系統。🧐

概述

關於定時執行任務的工具或框架系統有不少，通常狀況下針對不一樣的應用場景能夠選擇適合該場景下工具或框架。例如：若是不想引入其餘語言，只使用shell來執行的，可使用 linux Crontab 來執；若是是基於Spring 想着簡單實現一個定時任務，可使用@Scheduled註解。若是按照是否爲單獨的系統來分能夠分爲兩類：1. 系統或框架自帶的定時執行方法或工具。2. 單獨做爲一個服務的調度任務系統。

系統或框架自帶的定時執行方法或工具

Linux Crontab

只能單機執行與linux機器固定綁定，能夠經過cron 表達式定時執行shell腳本。簡單易使用，很差後期維護，只能執行shell腳本。

Java 原生的定時器Timer

優勢：簡單，不用引入其餘框架。

缺點：

1. Timer在執行全部定時任務時只會建立一個線程，若是某個任務的執行時間過長，那麼將破壞其餘TimerTask的定時精確性
2. 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任務的缺點

1. 只能在單個服務器上運行，或者在多個服務器上集羣運行，在單個數據庫的狀況下，不能指定不一樣服務器運行不一樣任務。

爲了解決原生Quartz的肯定，咱們基於Quartz和GRPC框架來開發任務調度系統，具體方案以下：

1. 利用一臺服務器部署quartz服務和做爲服務註冊中心（rpc調用中心）。
2. 經過建立不一樣的cron定時任務，經過傳入服務器地址，要執行的方法，定時遠程rpc調用不一樣服務器上的方法。
3. 定義每一個master和slaver都定義http請求調度，命令行請求調度和郵箱發送請求調度，當不須要指定執行機器時，則經過隨機找一個slaver去執行。

第一版項目地址：https://github.com/KANLON/job-scheduling (這個還不太完善，目前執行還不支持執行的高可用，後面須要修改執行任務的機器爲一個列表，遍歷該列表執行)

總結

若是沒有時間或資源搭一套調度任務系統，可使用系統或框架自帶的定時執行方法或工具來簡單使用。若是須要統一管理，方便後期維護建議首先使用開源系統的。開源的分佈式調度任務系統中建議使用xxl-job，該開源系統社區活躍度高，使用的公司數量相對較多，並且一直有在維護。

如下是我整理的思惟導圖：