分布式任務調度平臺構建方案

吳宇星

摘 要：IT系統都免不了存在定時任務，傳統的（JAVA體系）系統建設開發定時任務一般都是使用quartz或者spring-task，但是這兩種方案都缺乏集群能力，難以進行水平擴展。隨著大數據技術發展系統定時任務的服務很多，需要有統一定時任務調度服務提供定時任務的調度、管理、監控、高可用性、可擴展性。本文就基于Quartz構建分布式任務調度方案進行闡述。

關鍵詞：分布式;任務;Quartz;監控

1.引言

現在IT系統都免不了存在定時任務，需要實現分布式任務調度平臺，具備把定時任務通過集群的方式進行管理調度，并采用分布式部署，保證系統的高可用，提高了容錯。那么如何保證定時任務只在集群的某一個節點上執行，或者一個任務如何拆分為多個獨立的任務項，由分布式的機器去分別執行。

2.功能需求

分布式任務調度平臺常用于高并發，高可用的定時任務處理，如：定時發送消息，處理業務數據，并需要具備特殊時候可人為干預。

總體能力目標：

√定時任務配置功能

包括任務的注冊、取消功能。配置任務對應任務組。執行的任務中可以根據IP和端口進行擴充。實現定時規則的配置。

√定時任務的監控功能

監控當前任務組的狀態，是否正在執行，有多少個任務在執行。

√支持定時任務的動態擴展

按定時任務配置的規則進行輪詢。

√定時任務執行

支持配置定時任務后，N秒后生效。輪循進程開如輪循。

具體的技術目標：

√集群管理調度，分布式部署，保證系統的高可用性、伸縮性、負載均衡;

√友好的操作界面，通過控制臺部署管理任務，方便靈活高效;

√任務持久化于數據庫，遠離宕機和數據丟失隱患，完善的任務失敗重做機制，及詳細的任務跟蹤及告警策略;

√Server和Client分別支持集群和分布式部署;

√任務的執行與調度分離;

√任務支持異步調度;

√任務狀態持久化于DB;

√完善的日志跟蹤和告警策略。

3.建設方案

3.1.總體方案

分布式任務調度平臺是基于Quartz的定時輪詢功能，進行改造成服務端執行端分離模式，實現應用調度分布式型的結構，以及應用跟實際調度解耦：

WEB集群實現界面配置功能、并支持Quartz的定時解析，保證集群內一次只有一個服務支持定時任務，對任務的解析通過Quartz解析;

任務管理器負責任務的注冊、停止、暫時以及保存狀態信息;

為保證業務與定時功能的分離。任務對應的消息隊列在數據庫配置。為保證對原有代碼的侵入性最小，任務不需要實現監聽器。只需要在任務的service抽象類中實現監聽器進行監聽;

采用通用RPC服務框架進行定時任務的通訊，支撐異步操作，響應快。實現動態擴充服務來滿足定時任務的處理要求，滿足高可用的要求。

分布式任務調度平臺具備如下主要特點：

負載均衡：執行端可集群部署，服務端會自動實現負載均衡調度;

分布式：根據模或其他方式的參數任務分配，實現同一批數據多個實例分配處理;

轉移告警：任務配置超時且策略為轉移情況下，應用卡死的任務會進行中斷后轉移到其他集群節點執行;

軌跡記錄：根據任務運行的各個環節，以及節點，組成一條鏈的軌跡。

3.2.功能方案

分布式任務調度平臺主要由四部分組成，管理端、客戶端、服務端、執行端。由服務端進行管控派發任務，執行端來執行相應的任務，客戶端進行提供對外的Java通信交互接口，Admin Web進行操作任務。

3.2.1.管理端

1）任務的注冊、取消與暫停、手動啟動，任務需要定義名稱，綁定具體的任務執行器（JAVA類）上。

2）定時規則的配置，采用界面化配置，基于Quartz擴展，并且支持cron表達式。

3）增加或刪除服務到任務上。具備按IP與端口增加或刪除任務到任務組上。

4）任務和任務組的監控，具備監控調用日志實現任務執行狀態查看。

3.2.2.客戶端

1）實現客戶端，支持進行任務的操作。在管理平臺的所有任務操作，全部由client端請求server端完成。

2）提供專門的對外接口類，只需要配置server端的地址即可new實例即可，可調用接口進行操作查詢任務，client跟server之間采用長連接，通信損耗時間要小，可忽略不計。

3.2.3.服務端

服務端對應用端的分布式調用，采用quartz每開始一個子任務，啟動一個線程去執行該子任務，直到子任務執行完畢就釋放。

3.2.4.執行端

執行端是任務執行的承載體，服務端下發的業務任務實際上有執行端進行運行。

1）具備任務線程池

需要自定義線程池，進行可管控的讓優先級高的任務進行優先執行。

2）可設定任務優先級

需要具備根據應用配置的任務優先級，進行調控優先級高的任務進行執行，優先級低的任務先排后面。

3）可上報執行信息

定時上報該執行端的線程池情況信息，包括工作中線程中對應的任務，方便線程dump分析應用的情況。

3.3.關鍵技術方案

3.3.1.任務軌跡查看

應用在查找任務不執行問題的時候，難以了解到任務的分部執行情況軌跡，以及服務端中各種任務的狀態匯總情況，需要具備界面化的查看任務的軌跡情況、集群情況。

解決方案：

1、為了方便數據的實時性，直接采用通過客戶端從服務端實時讀取內存中的數據。

3.3.2.任務手動調整

實際應用中，運用場景較為復雜，有時候需要對已經創建的子任務的數據進行修改（包含任務層面修改數據以及子任務層面修改數據），則不能修改的話必須重新刪除創建，如果子任務數量非常多，創建非常麻煩。

解決方案：

quartz目前版本并不支持修改子任務的對外接口或者可操作方法，則只能由客戶端操作進行先刪除重新新建的操作，但是要保證各個集群服務端中并無運行中的子任務、超時子任務等一切還未執行完畢的子任務存在。

3.3.3.任務均衡

任務分配任務算法是根據某個任務執行子任務的時候，如果某個應用有3個節點部署執行任務，創建了3個任務，每個任務的子任務數參考圖中解釋，單次觸發多個任務的時候，會造成分配不均情況。

解決方案：

每次分配任務的時候，先查看各個節點已經容納運行的子任務數量，然后做均衡算法分配到平均，每個節點運行數量相差個數不超過1。

3.3.4.異常重新執行

quartz提供異常任務的重新觸發機制以及暫停任務的機制，由于考慮到一期輪詢中quartz每觸發一個子任務都消耗一個線程，除了異常暫停任務外，異常重新觸發由服務端外部控制觸發，并不交給quartz來處理。

解決方案：

異常的任務每次落地到數據庫中，方便應用查看歷史的異常記錄情況。

4.結束語

本文就基于quartz設計實現分布式任務調度平臺方案進行介紹，并且目前該實現方案已經在項目中應用，在應用系統的任務的管理、運行上有了很大的提升，很好了支撐了業務系統中的后臺任務的運行，做到可管、可控，并且具備水平擴展能力。

參考文獻：

[1] 分布式定時任務調度框架.https：//www.jianshu.com/p/ab438d944669