基于XXL-JOB的可視化分布式定時調(diào)度平臺的設(shè)計與實現(xiàn)

陸穎

關(guān)鍵詞：定時任務(wù)；微服務(wù)；分布式；XXL-JOB；可視化

中圖分類號：TP319 文獻標識碼：A

文章編號：1009-3044（2023）14-0039-03

0 引言

定時任務(wù)是指按照特定時間周期運行的任務(wù)。使用場景為在某個固定時間運行或者周期性地去執(zhí)行某個任務(wù)，比如：每天24點做數(shù)據(jù)匯總，定時發(fā)送短信等。定時任務(wù)分為單機定時任務(wù)和分布式調(diào)度任務(wù)。Timer、SpringTask、ScheduledExcetorService 等均屬于單機定時任務(wù)，單機定時任務(wù)操作簡單，容易實現(xiàn)，但存在與業(yè)務(wù)邏輯緊耦合、不支持分片任務(wù)、任務(wù)失敗無報警機制，集群化部署難以保證任務(wù)的冪等性等缺陷[1]。分布式定時任務(wù)具備支持動態(tài)配置定時規(guī)則，集群化部署可以保證job冪等性等優(yōu)勢。XXLJOB作為一種分布式定時框架，具備可視化管理，配置靈活，可拓展性高等特性。

1 定時任務(wù)框架性能對比

1.1 XXL-JOB簡介

XXL-JOB將調(diào)度行為抽象成一個不承擔(dān)業(yè)務(wù)邏輯的調(diào)度中心公共平臺，平臺負責(zé)集中管理調(diào)度信息，依據(jù)調(diào)度配置進行調(diào)度請求，支持界面化動態(tài)配置任務(wù)報警、任務(wù)新建、任務(wù)修改、任務(wù)刪除等管理信息，配置完成即刻生效。XXL-JOB通過執(zhí)行器統(tǒng)一管理拆分的多個JobHandler[2]，依據(jù)接收到的調(diào)度請求，處理相應(yīng)JobHandler中的業(yè)務(wù)模塊。這種將調(diào)度中心和執(zhí)行器分離的分布式定時框架實現(xiàn)了業(yè)務(wù)邏輯的解耦，提高了項目運行的穩(wěn)定性，程序代碼的可重用性以及系統(tǒng)的可擴展性。

1.2 Elastic-JOB簡介

Elastic-JOB[3]是當(dāng)當(dāng)網(wǎng)推出的分布式任務(wù)調(diào)度框架，由Elastic-Job-Lite 和Elastic-Job-Cloud 兩個相對獨立的子項目組成。主要的設(shè)計理念是無中心化的分布式定時調(diào)度框架。它采用Zookeeper實現(xiàn)分布式協(xié)調(diào)，任務(wù)高可用以及分片，具備彈性擴容縮容，定制化流程型任務(wù)等功能。

1.3 Quartz簡介

Quartz是由OpenSymphony組織開發(fā)出來的開源且具有豐富特性的任務(wù)調(diào)度庫，主要由Job Detail、Job、Scheduler、Trigger四個核心類構(gòu)成[4]。Quartz能創(chuàng)建亦簡單亦復(fù)雜的調(diào)度，具備強大的調(diào)度功能與靈活的應(yīng)用方式，但存在時間規(guī)則更改無法實時生效，沒有可視化管理界面等缺陷。

上述三種分布式定時任務(wù)框架的性能對比如表1 所示。

2 XXL-JOB 工作原理

2.1 執(zhí)行器注冊

任務(wù)執(zhí)行器根據(jù)配置的調(diào)度中心的地址，啟動注冊線程向調(diào)度中心的執(zhí)行器管理發(fā)起自動注冊。也可以人工手動錄入執(zhí)行器的地址信息，多地址逗號分隔，供調(diào)度中心發(fā)起注冊。

2.2 任務(wù)下發(fā)

執(zhí)行器管理中保存著注冊執(zhí)行器，后續(xù)會根據(jù)這個注冊信息給執(zhí)行器下發(fā)任務(wù)。如果此時有需要執(zhí)行的任務(wù)，任務(wù)管理模塊會根據(jù)執(zhí)行器管理中注冊的執(zhí)行器信息，向任務(wù)執(zhí)行器下發(fā)任務(wù)。任務(wù)執(zhí)行器中的任務(wù)執(zhí)行服務(wù)接受到任務(wù)以后會將任務(wù)發(fā)送到待執(zhí)行任務(wù)的隊列中，隊列中的任務(wù)會由執(zhí)行線程Job?Handler依次獲取并且執(zhí)行。這里會維護一個任務(wù)執(zhí)行的線程池，池中就是一個個JobHandler線程，它們是執(zhí)行任務(wù)的主力軍。

2.3 執(zhí)行結(jié)果異步上報

JobHandler執(zhí)行器基于線程池執(zhí)行任務(wù)，并把執(zhí)行結(jié)果放入執(zhí)行結(jié)果隊列中，同時會把執(zhí)行日志寫入任務(wù)日志文件中，以供日志查詢。然后通知回調(diào)線程，告知任務(wù)執(zhí)行完畢，回調(diào)線程會通知調(diào)度中心的監(jiān)控運維模塊，任務(wù)執(zhí)行完畢。

2.4 日志查詢請求

用戶可以在調(diào)度中心查看任務(wù)日志，其過程是通過發(fā)送日志查詢請求給任務(wù)執(zhí)行器中的日志服務(wù)，然后查詢?nèi)蝿?wù)日志文件實現(xiàn)。在任務(wù)日志界面中，可查看該任務(wù)的歷史調(diào)度信息、執(zhí)行參數(shù)和執(zhí)行信息，進入日志控制臺可查看實時執(zhí)行日志[5]。

XXL-JOB具體任務(wù)執(zhí)行流程如圖1所示。

3 平臺設(shè)計與實現(xiàn)

3.1 項目功能概述

智慧文旅融合大數(shù)據(jù)平臺項目集成省級以下各景點游玩信息，包含當(dāng)?shù)靥鞖鉅顩r、景區(qū)視頻監(jiān)控、道路擁擠情況、門票售賣統(tǒng)計、景區(qū)點評好壞等信息，涵蓋了游前、游中、游后各項服務(wù)要素。平臺主要包含以下功能點。

1）用戶信息管理：市級管理員查看該城市下所有景點的相關(guān)信息，省級管理員查看該省下所有的景點數(shù)據(jù)。

2）監(jiān)控管理：平臺接入管轄內(nèi)所有景點的視頻攝像，切換景區(qū)后，可以看到該景區(qū)下所有攝像頭拍攝到的實時畫面，利于負責(zé)人實時查看景區(qū)狀況。

3）數(shù)據(jù)統(tǒng)計管理：平臺統(tǒng)計分析天氣、道路、售票、點評等各項數(shù)據(jù)狀況，通過圖表的方式進行統(tǒng)計展示。

4）信息管理：遇到道路擁擠、天氣惡劣等異常情況會進行預(yù)警提醒。

3.2 軟件架構(gòu)設(shè)計

平臺采用B/S架構(gòu)，使用SpringBoot+Vue 前后端分離技術(shù)實現(xiàn)[6]。后端采用基于MVVM模型的Spring?Boot框架[7]集成XXL-JOB的方式定時收集目標數(shù)據(jù)，經(jīng)過邏輯處理后的數(shù)據(jù)通過MyBatis-PLUS數(shù)據(jù)持久層框架進行保存。為了減少與MySQL關(guān)系型數(shù)據(jù)庫的交互，系統(tǒng)采用對待保存數(shù)據(jù)進行分段處理后再批量保存的方式存儲數(shù)據(jù)，一定程度上大大提高了執(zhí)行效率。前端使用Vue+Element-UI[8]的方式開發(fā)管理界面，Echarts[9]組件進行數(shù)據(jù)的圖表化展示。

3.3 開發(fā)環(huán)境

開發(fā)平臺借助Win10 平臺，采用Visual StudioCode、IDEA、Navicat等開發(fā)工具。編程語言包括Java、JavaScript、Vue、Element-UI、CSS等，Java開發(fā)環(huán)境使用JDK8。通過Git對項目源代碼進行統(tǒng)一管理，其中包括代碼分支的管理與項目版本迭代的控制等。

3.4 定時應(yīng)用

在智慧文旅大數(shù)據(jù)平臺項目中，XXL-JOB主要應(yīng)用于天氣狀況、道路擁堵、第三方評價三大模塊的數(shù)據(jù)同步統(tǒng)計中，具體概述如下。

1）天氣數(shù)據(jù)方面：天氣數(shù)據(jù)包括實時溫度、體感溫度、風(fēng)力風(fēng)向、相對濕度、大氣壓強、降水量、能見度、露點溫度、云量等。通過和風(fēng)天氣Api統(tǒng)計中國3000+市縣區(qū)當(dāng)日以及未來7天的天氣數(shù)據(jù)。

2）道路數(shù)據(jù)方面：通過百度地圖Api統(tǒng)計所有景區(qū)附近道路的擁堵評價、擁堵距離、擁堵趨勢等信息。

3）第三方平臺數(shù)據(jù)方面：定時拉取美團、大眾點評、攜程、飛豬等第三方平臺的售票與點評狀況，對數(shù)據(jù)進行統(tǒng)計分析。

平臺對三大模塊中定時抽取獲得的原始數(shù)據(jù)進行清洗，刪除不必要的臟數(shù)據(jù)，修補并完善異常數(shù)據(jù)，然后按照預(yù)先設(shè)計的規(guī)則進行數(shù)據(jù)處理，處理完成的數(shù)據(jù)最終存儲至數(shù)據(jù)庫表對應(yīng)的字段中。同時，平臺通過可視化界面配置任務(wù)報警機制來保證異常任務(wù)的及時處理，比如：當(dāng)定時任務(wù)執(zhí)行失敗時，會給配置的郵箱發(fā)送信息，提醒負責(zé)人進行排查處理。

3.5 分片廣播策略

XXL-JOB 具有輪詢、隨機、故障轉(zhuǎn)移、一致性HASH、分片廣播等多種路由策略。在選擇“分片廣播”路由策略的場景下，執(zhí)行一次任務(wù)調(diào)度可以廣播實現(xiàn)集群環(huán)境中全部的執(zhí)行器完成一次任務(wù)操作，實現(xiàn)服務(wù)資源最大限度調(diào)用，根據(jù)系統(tǒng)自動傳播的分片參數(shù)完成業(yè)務(wù)處理。

鑒于所需統(tǒng)計的數(shù)據(jù)量較大，平臺采用分片廣播的路由策略將執(zhí)行壓力均衡分散到所有服務(wù)器節(jié)點。在分片定時任務(wù)邏輯里，根據(jù)獲取到的分片序號、分片總數(shù)、執(zhí)行任務(wù)節(jié)點數(shù)量，決策當(dāng)前節(jié)點是否需要執(zhí)行。具體判斷公式如式（1）所示：

其中id表示數(shù)據(jù)id，n表示總分片數(shù)，i表示當(dāng)前分片數(shù)。通過數(shù)據(jù)id的值對總分片數(shù)進行求余，求余后的數(shù)正好等于系統(tǒng)的當(dāng)前分片數(shù)的方式來巧妙地實現(xiàn)天氣、道路、第三方數(shù)據(jù)的統(tǒng)計，實現(xiàn)靈活調(diào)度[1， N] 個節(jié)點并行執(zhí)行任務(wù)。其中分片處理的核心偽代碼如下：

3.6 部署方式

文旅項目采用Docker[10]集群部署的方式，部署一個調(diào)度中心，在減少數(shù)據(jù)庫壓力與保證運行效率的情況下部署盡可能多的執(zhí)行器。這種容器化的部署具備跨平臺、成本低、集成便捷等優(yōu)勢。

4 結(jié)束語

筆者剖析了三種分布式任務(wù)系統(tǒng)的優(yōu)缺點，詳細描述了XXL-JOB的工作原理，并概述了XXL-JOB在文旅大平臺項目中的設(shè)計與應(yīng)用。XXL-JOB分布式定時任務(wù)框架具備開發(fā)迅速、學(xué)習(xí)簡單、可視化管理界面使用便捷等優(yōu)點，在保證穩(wěn)定運行的情況下，大大減少了開發(fā)人員的時間和精力。但是，在調(diào)度中心和執(zhí)行器集群數(shù)量不斷增加的場景下，數(shù)據(jù)庫鎖競爭壓力大。因此，如何減輕DB鎖壓力將是下一步的研究方向。