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

吳宇星

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

關鍵詞：分布式;任務;Quartz;監(jiān)控

1.引言

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

2.功能需求

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

總體能力目標：

√定時任務配置功能

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

√定時任務的監(jiān)控功能

監(jiān)控當前任務組的狀態(tài)，是否正在執(zhí)行，有多少個任務在執(zhí)行。

√支持定時任務的動態(tài)擴展

按定時任務配置的規(guī)則進行輪詢。

√定時任務執(zhí)行

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

具體的技術目標：

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

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

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

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

√任務的執(zhí)行與調度分離;

√任務支持異步調度;

√任務狀態(tài)持久化于DB;

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

3.建設方案

3.1.總體方案

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

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

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

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

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

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

負載均衡：執(zhí)行端可集群部署，服務端會自動實現(xiàn)負載均衡調度;

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

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

軌跡記錄：根據任務運行的各個環(huán)節(jié)，以及節(jié)點，組成一條鏈的軌跡。

3.2.功能方案

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

3.2.1.管理端

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

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

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

4）任務和任務組的監(jiān)控，具備監(jiān)控調用日志實現(xiàn)任務執(zhí)行狀態(tài)查看。

3.2.2.客戶端

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

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

3.2.3.服務端

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

3.2.4.執(zhí)行端

執(zhí)行端是任務執(zhí)行的承載體，服務端下發(fā)的業(yè)務任務實際上有執(zhí)行端進行運行。

1）具備任務線程池

需要自定義線程池，進行可管控的讓優(yōu)先級高的任務進行優(yōu)先執(zhí)行。

2）可設定任務優(yōu)先級

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

3）可上報執(zhí)行信息

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

3.3.關鍵技術方案

3.3.1.任務軌跡查看

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

解決方案：

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

3.3.2.任務手動調整

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

解決方案：

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

3.3.3.任務均衡

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

解決方案：

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

3.3.4.異常重新執(zhí)行

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

解決方案：

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

4.結束語

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

參考文獻：

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