陸穎

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

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

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

0 引言

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

1 定時任務框架性能對比

1.1 XXL-JOB簡介

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

1.2 Elastic-JOB簡介

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

1.3 Quartz簡介

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

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

2 XXL-JOB 工作原理

2.1 執(zhí)行器注冊

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

2.2 任務下發(fā)

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

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

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

2.4 日志查詢請求

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

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

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

3.1 項目功能概述

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

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

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

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

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

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 定時應用

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

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

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

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

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

3.5 分片廣播策略

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

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

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

3.6 部署方式

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

4 結(jié)束語

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