丁文婷 卜言彬

摘要：隨著信息化技術(shù)的不斷發(fā)展，微服務(wù)架構(gòu)成為主流軟件開發(fā)架構(gòu)，傳統(tǒng)的定時(shí)任務(wù)存在執(zhí)行效率低、容錯(cuò)機(jī)制差、單點(diǎn)故障無(wú)法恢復(fù)、管理功能不完善等問題，已漸漸無(wú)法滿足業(yè)務(wù)需要。Elastic-Job分布式定時(shí)任務(wù)框架支持動(dòng)態(tài)注冊(cè)微服務(wù)、分片執(zhí)行定時(shí)任務(wù)效率高、容錯(cuò)機(jī)制完善、任務(wù)管理方便等優(yōu)點(diǎn)，為海量數(shù)據(jù)的互聯(lián)網(wǎng)應(yīng)用開發(fā)提供了很好的解決方案。文章重點(diǎn)對(duì)Elastic-Job進(jìn)行了研究并在互聯(lián)網(wǎng)企業(yè)級(jí)系統(tǒng)開發(fā)中進(jìn)行實(shí)踐，提高了執(zhí)行的效率和準(zhǔn)確率，并且達(dá)到了自動(dòng)化運(yùn)維的目的。

關(guān)鍵詞：定時(shí)任務(wù)；分布式；Elastic-Job；微服務(wù)；自動(dòng)化運(yùn)維

中圖分類號(hào)：TP399? ? ? 文獻(xiàn)標(biāo)識(shí)碼：A

文章編號(hào)：1009-3044（2024）07-0033-04

開放科學(xué)（資源服務(wù)）標(biāo)識(shí)碼（OSID）

0 引言

定時(shí)任務(wù)是指按照特定時(shí)間周期運(yùn)行的任務(wù)。使用場(chǎng)景為在某個(gè)固定時(shí)間運(yùn)行或者周期性地執(zhí)行某個(gè)任務(wù)，例如：每天24點(diǎn)做數(shù)據(jù)匯總，定時(shí)發(fā)送短信等[1]。傳統(tǒng)的定時(shí)任務(wù)在單臺(tái)服務(wù)器節(jié)點(diǎn)上進(jìn)行部署，一旦因?yàn)榫W(wǎng)絡(luò)等原因造成的出錯(cuò)，定時(shí)任務(wù)將停止執(zhí)行，這種單點(diǎn)部署的方式存在故障無(wú)法恢復(fù)、容錯(cuò)機(jī)制較差等問題。隨著互聯(lián)網(wǎng)業(yè)務(wù)的興起，海量數(shù)據(jù)處理的定時(shí)任務(wù)需求越來越多，開發(fā)者對(duì)定時(shí)任務(wù)執(zhí)行效率的需求也在不斷提升，例如24點(diǎn)做數(shù)據(jù)匯總定時(shí)發(fā)短信的功能要在1小時(shí)內(nèi)完成，若數(shù)據(jù)量過大，單個(gè)節(jié)點(diǎn)處理存在效率低下無(wú)法滿足要求的問題。分布式定時(shí)任務(wù)的出現(xiàn)很好地解決了以上問題，并提供了可視化界面管理定時(shí)任務(wù)。Elastic-Job分布式定時(shí)任務(wù)具有可彈性擴(kuò)容、多線程處理定時(shí)任務(wù)效率高、失敗容錯(cuò)機(jī)制好、具備冪等性等特點(diǎn)，適用于互聯(lián)網(wǎng)企業(yè)海量數(shù)據(jù)的應(yīng)用系統(tǒng)服務(wù)開發(fā)。

1 定時(shí)任務(wù)框架比對(duì)

1.1 Quartz框架

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

1.2 XXL-JOB框架

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

1.3 Elastic-Job框架

Elastic-Job是當(dāng)當(dāng)網(wǎng)開源的分布式任務(wù)調(diào)度框架，用于解決分布式任務(wù)的協(xié)調(diào)調(diào)度問題，是面向互聯(lián)網(wǎng)生態(tài)和海量任務(wù)的適用于互聯(lián)網(wǎng)場(chǎng)景的分布式調(diào)度解決方案。Elastic-Job具有彈性調(diào)度、資源管控以及作業(yè)治理的功能，并通過開放的架構(gòu)設(shè)計(jì)，提供多元化作業(yè)生態(tài)。Elastic-Job不依賴MySQL數(shù)據(jù)庫(kù)，不存在數(shù)據(jù)庫(kù)鎖競(jìng)爭(zhēng)的問題。

上述三種定時(shí)任務(wù)框架的對(duì)比如表1所示。

2 Elastic-Job的研究

2.1 Elastic-Job的整體架構(gòu)

Elastic-Job是基于Zookeeper、Quartz開發(fā)的Java分布式定時(shí)任務(wù)框架，解決了Quartz不支持分布式的問題。該框架主要的功能有支持彈性擴(kuò)容、通過Zookeeper集中管理和監(jiān)控Job、支持失效轉(zhuǎn)移等。該項(xiàng)目由兩個(gè)相互獨(dú)立的子項(xiàng)目Elastic-Job-Lite和Elastic-Job-Cloud組成。

Elastic-Job-Lite定位為輕量級(jí)無(wú)中心化解決方案，以jar包的形式提供分布式任務(wù)的協(xié)調(diào)服務(wù)，其框架結(jié)構(gòu)如圖1所示。

App服務(wù)器，也稱App節(jié)點(diǎn)，內(nèi)含業(yè)務(wù)的定時(shí)任務(wù)，以jar的形式集成Elastic-Job-Lite相關(guān)組件，配置定時(shí)任務(wù)相關(guān)信息，可集群部署。

Elastic-Job-Lite負(fù)責(zé)作業(yè)的相關(guān)調(diào)度，產(chǎn)生任務(wù)調(diào)度記錄，Elastic-Job-Lite無(wú)中心化，每個(gè)節(jié)點(diǎn)的作業(yè)任務(wù)平等且自治，節(jié)點(diǎn)間通過注冊(cè)中心Registry進(jìn)行分布式調(diào)度。

Registry以Zookeeper為注冊(cè)中心，利用Zookeeper可進(jìn)行App節(jié)點(diǎn)的自動(dòng)注冊(cè)和發(fā)現(xiàn)的功能特性，以文件的形式保存正在執(zhí)行的定時(shí)任務(wù)的基本信息，如IP、定時(shí)任務(wù)名稱、執(zhí)行時(shí)間等，同時(shí)利用節(jié)點(diǎn)中集成的Elastic-Job進(jìn)行任務(wù)的實(shí)例選舉。Registry以REST API的形式提供接口供Console組件用于任務(wù)的運(yùn)維管理。

Console為運(yùn)維管理平臺(tái)，通過讀取Registry中的任務(wù)數(shù)據(jù)，展現(xiàn)任務(wù)的執(zhí)行狀態(tài)。運(yùn)維可通過Console查看歷史執(zhí)行任務(wù)，修改任務(wù)的配置達(dá)到控制任務(wù)執(zhí)行的目的，且無(wú)須重啟App節(jié)點(diǎn)，支持定時(shí)任務(wù)修改熱生效。

Elastic-Job-Cloud使用Mesos+Docker的解決方案，額外提供資源治理、應(yīng)用分發(fā)以及進(jìn)程隔離等功能。

Elastic-Job-Cloud和Elastic-Job-Lite的功能對(duì)于定時(shí)任務(wù)的處理類似，區(qū)別如表2所示。

Elastic-Job-Cloud的優(yōu)勢(shì)在于Docker[4]部署，對(duì)資源細(xì)粒度的治理，非常適用于需要削峰填谷的大數(shù)據(jù)系統(tǒng)。

2.2 作業(yè)類型

Elastic-Job提供Simple、Dataflow和Script三種作業(yè)類型。

1） Simple類型。Simple作業(yè)類型未經(jīng)任何封裝，開發(fā)者需實(shí)現(xiàn)SimpleJob接口，該接口僅提供execute方法用于任務(wù)處理，execute方法定時(shí)執(zhí)行，提供分片號(hào)等參數(shù)，開發(fā)者使用時(shí)與Quartz原生接口相似，利用分片號(hào)處理對(duì)應(yīng)分片數(shù)據(jù)。

2） Dataflow類型。Dataflow作業(yè)類型用于處理數(shù)據(jù)流，需實(shí)現(xiàn)DataflowJob接口。該接口提供兩個(gè)方法可供實(shí)現(xiàn)，分別用于抓取和處理數(shù)據(jù)，fetchDate方法抓取要處理的數(shù)據(jù)，processData方法處理抓取的數(shù)據(jù)。

3） Script類型。Script作業(yè)類型為腳本類型作業(yè)，支持Shell、Python、Perl等類型腳本。開發(fā)者只需通過控制臺(tái)或代碼配置scriptCommandLine即可，無(wú)須編碼，執(zhí)行腳本路徑可包含參數(shù)，參數(shù)傳遞完畢后，作業(yè)框架自動(dòng)追加最后一個(gè)參數(shù)作為作業(yè)運(yùn)行時(shí)信息。

2.3 作業(yè)分片策略

非常耗時(shí)的定時(shí)任務(wù)，例如一次處理一億條數(shù)據(jù)，用一個(gè)節(jié)點(diǎn)可能要處理很久，在互聯(lián)網(wǎng)領(lǐng)域一般通過橫向擴(kuò)展節(jié)點(diǎn)來縮短處理時(shí)長(zhǎng)，Elastic-Job把作業(yè)分為多個(gè)分片任務(wù)，每個(gè)分片交給一個(gè)節(jié)點(diǎn)去執(zhí)行，一個(gè)節(jié)點(diǎn)可處理多個(gè)分片，每個(gè)分片的處理邏輯可由節(jié)點(diǎn)自身決定。

Elastic-Job提供三種任務(wù)分片策略，分別為平均分片策略、根據(jù)作業(yè)名的哈希值奇偶數(shù)決定IP升降序算法的分片策略、根據(jù)作業(yè)名的哈希值對(duì)服務(wù)器列表進(jìn)行輪轉(zhuǎn)的分片策略。

平均分配策略為默認(rèn)策略，也是使用最多的策略。假設(shè)有3個(gè)App節(jié)點(diǎn)處理同一個(gè)任務(wù)，若任務(wù)被分成0～8共9片，則每個(gè)App分到的分片為App1=[0，1，2]，App2=[3，4，5]，App3=[6，7，8]。若任務(wù)被分成0-7共8片，則每個(gè)App分到的分片為App1=[0，1，6]，App2=[2，3，7]，App3=[4，5]。若任務(wù)被分成0～9共10片，則每個(gè)App分到的分片為App1=[0，1，2，9]，App2=[3，4，5]，App3=[6，7，8]。由此可見，任務(wù)的執(zhí)行時(shí)間可縮短約三分之二。

此外分片策略支持自定義擴(kuò)展，若考慮到App節(jié)點(diǎn)每臺(tái)的負(fù)載不同，開發(fā)者可自定義策略進(jìn)行分片任務(wù)處理的調(diào)整。

2.4 Elastic-Job工作原理

Elastic-Job通過jar包形式集成到App節(jié)點(diǎn)，首個(gè)節(jié)點(diǎn)啟動(dòng)后由監(jiān)聽器觸發(fā)主節(jié)點(diǎn)選舉，并使用鎖阻塞其他節(jié)點(diǎn)執(zhí)行任務(wù)，主節(jié)點(diǎn)選舉完畢后其他節(jié)點(diǎn)方能執(zhí)行任務(wù)。

任一節(jié)點(diǎn)啟動(dòng)后節(jié)點(diǎn)信息被自動(dòng)注冊(cè)到Zookeeper，節(jié)點(diǎn)下線時(shí)Zookeeper自動(dòng)更新節(jié)點(diǎn)信息。主節(jié)點(diǎn)選舉、節(jié)點(diǎn)上下線、分片總數(shù)修改均更新重新分片標(biāo)記，分片過程中若主節(jié)點(diǎn)下線，則先選舉主節(jié)點(diǎn)，再重新分片。

定時(shí)任務(wù)觸發(fā)時(shí)，節(jié)點(diǎn)首先檢查分片標(biāo)記，若需要重新分片，則通過主節(jié)點(diǎn)重新分片，分片過程阻塞，結(jié)束后方能執(zhí)行任務(wù)。任務(wù)運(yùn)行過程中只標(biāo)記重新分片標(biāo)記而不重新分片，下次任務(wù)執(zhí)行前重新分片。

節(jié)點(diǎn)執(zhí)行完任務(wù)后主動(dòng)抓取未分配的分片任務(wù)，并在某節(jié)點(diǎn)下線后主動(dòng)尋找可用的其他節(jié)點(diǎn)執(zhí)行分片，由此實(shí)現(xiàn)了分片任務(wù)的失效轉(zhuǎn)移，任務(wù)不停止執(zhí)行，從而提高容錯(cuò)性。

2.5 失效轉(zhuǎn)移

Elastic-Job不在執(zhí)行過程中重新分片，而是等待下次調(diào)度之前才重新分片，當(dāng)任務(wù)執(zhí)行過程中服務(wù)器宕機(jī)，Elastic-Job允許此次未完成的任務(wù)在另一任務(wù)節(jié)點(diǎn)上補(bǔ)償執(zhí)行。

失效轉(zhuǎn)移是當(dāng)前執(zhí)行任務(wù)的臨時(shí)補(bǔ)償執(zhí)行機(jī)制，下次任務(wù)運(yùn)行時(shí)，Elastic-Job通過重新分片對(duì)當(dāng)前任務(wù)分配進(jìn)行調(diào)整。開啟失效轉(zhuǎn)移功能，Elastic-Job將監(jiān)控作業(yè)每一分片的執(zhí)行狀態(tài)，并將其寫入Zookeeper，供其他節(jié)點(diǎn)感知。

一次運(yùn)行耗時(shí)較長(zhǎng)且間隔較長(zhǎng)的作業(yè)場(chǎng)景，失效轉(zhuǎn)移是提升作業(yè)運(yùn)行實(shí)時(shí)性的有效手段。此外任務(wù)本身須具有冪等性，即故障轉(zhuǎn)移到新的節(jié)點(diǎn)上執(zhí)行時(shí)，業(yè)務(wù)數(shù)據(jù)不能重復(fù)執(zhí)行，已經(jīng)執(zhí)行過的數(shù)據(jù)要在業(yè)務(wù)代碼上進(jìn)行冪等性的處理，以保證失效轉(zhuǎn)移的正確性。

3 實(shí)踐和應(yīng)用

3.1 項(xiàng)目功能描述

互聯(lián)網(wǎng)電商企業(yè)應(yīng)用開發(fā)中，存在上百個(gè)微服務(wù)模塊處理不同的業(yè)務(wù)，如訂單、訂購(gòu)、用戶、支付等不同模塊，每個(gè)模塊微服務(wù)以集群方式部署，某些定時(shí)任務(wù)如更新訂購(gòu)關(guān)系狀態(tài)、更新訂單狀態(tài)等任務(wù)的處理耗時(shí)非常長(zhǎng)，任務(wù)出錯(cuò)后無(wú)法自動(dòng)恢復(fù)，容錯(cuò)機(jī)制差，運(yùn)維工程師期望這些定時(shí)任務(wù)可通過統(tǒng)一的任務(wù)管理平臺(tái)進(jìn)行查看和管理，因此引入Elastic-Job-Lite框架。

3.2 Zookeeper部署及其作用

本電商平臺(tái)Zookeeper部署在Linux環(huán)境下，安裝JDK1.8及Zookeeper3.6版本，在每個(gè)節(jié)點(diǎn)創(chuàng)建節(jié)點(diǎn)目錄、日志目錄以及myid文件。

Zookeeper是一個(gè)分布式一致性協(xié)調(diào)服務(wù)，是Apache Hadoop下的一個(gè)子項(xiàng)目，主要用來解決分布式應(yīng)用中經(jīng)常遇到的一些數(shù)據(jù)管理問題，如：統(tǒng)一命名服務(wù)、狀態(tài)同步服務(wù)、集群管理、分布式應(yīng)用配置項(xiàng)的管理等。Zookeeper維護(hù)一個(gè)類似文件系統(tǒng)的樹形數(shù)據(jù)結(jié)構(gòu)，其客戶端（如Elastic-Job任務(wù)執(zhí)行實(shí)例）可對(duì)數(shù)據(jù)進(jìn)行讀取，每個(gè)子目錄項(xiàng)如“/app1”都被稱作znode目錄節(jié)點(diǎn)。Zookeeper和文件系統(tǒng)相同，可自由增加、刪除znode，可在znode下增加、刪除子znode，唯一的不同在于znode可存儲(chǔ)數(shù)據(jù)。

Zookeeper擁有數(shù)據(jù)監(jiān)聽通知機(jī)制，客戶端注冊(cè)監(jiān)聽znode，當(dāng)znode發(fā)生變化，如數(shù)據(jù)改變、znode被刪除、子節(jié)點(diǎn)增加刪除時(shí)，Zookeeper通知所有客戶端。

Elastic-Job依賴于Zookeeper進(jìn)行任務(wù)信息存儲(chǔ)和主節(jié)點(diǎn)選舉。任務(wù)信息包括任務(wù)名稱、任務(wù)實(shí)例節(jié)點(diǎn)信息、任務(wù)執(zhí)行策略。在任務(wù)的實(shí)例節(jié)點(diǎn)數(shù)量發(fā)生變化時(shí)，Elastic-Job重新觸發(fā)選舉機(jī)制。

3.3 微服務(wù)改造

本電商平臺(tái)微服務(wù)采用SpringBoot開發(fā)，集成Elastic-Job時(shí)須在配置文件中配置任務(wù)相關(guān)信息和Zookeeper信息，微服務(wù)的定時(shí)任務(wù)處理時(shí)根據(jù)作業(yè)類型實(shí)現(xiàn)Elastic-Job提供的不同接口，Simple類型的作業(yè)實(shí)現(xiàn)SimpleJob接口，Dataflow類型的作業(yè)實(shí)現(xiàn)DataflowJob接口。

以訂購(gòu)模塊的更新訂購(gòu)關(guān)系狀態(tài)的任務(wù)為例，采用SimpleJob作業(yè)類型，集成Elastic-Job-Lite框架時(shí)，須修改以下信息。

1） 配置文件。配置文件須配置注冊(cè)中心Zookeeper信息以及定時(shí)任務(wù)相關(guān)參數(shù)，如：

elasticjob：

#注冊(cè)中心配置

regCenter：

#Zookeeper的ip和端口

serverLists： localhost：2181

#命名空間，模塊名命名分離不同模塊的任務(wù)

namespace： subscription

#定時(shí)任務(wù)配置

jobs：

#自定義的任務(wù)名稱

jobA：

#對(duì)應(yīng)的類

elasticJobClass： com.cucn.job.JobA

cron： 0/10 * * * * ？

#自定義參數(shù)

jobParameter：

#分片總數(shù)

shardingTotalCount： 3

#自定義的分片參數(shù)

shardingItemParameters：

2） 作業(yè)任務(wù)代碼。訂單模塊的微服務(wù)中使用Simple類型的作業(yè)實(shí)現(xiàn)SimpleJob接口，通過ShardingContext類的getShardingItem方法獲取分片號(hào)，根據(jù)分片號(hào)獲取該分片要處理的數(shù)據(jù)并進(jìn)行處理。例如根據(jù)分片號(hào)獲取訂單分表的數(shù)據(jù)，只須將分片號(hào)作為參數(shù)傳入表名獲取該分片對(duì)應(yīng)的分表信息進(jìn)行處理。

JobA代碼如下：

@Component

public class JobA implements SimpleJob {

private final Logger logger = LoggerFactory.getLogger（JobA.class）;

@Autowired

private OrderService orderService;

@Override

public void execute（ShardingContext context） {

logger.info（"JobA execute start...item： {}|param： {}"，

context.getShardingItem（）， context.getShardingParameter（））;

try{

// 通過分片號(hào)和參數(shù)獲取要處理的分表數(shù)據(jù)

List orders= orderService.findOrders（context.getShardingItem（）， context.getShardingParameter（））;

// 處理數(shù)據(jù)

for （Order order： orders） {

orderService.setCompleted（order.getId（））;

}

}

catch（Exception e）{

logger.error（"JobA execute failed...item={}，param={}"，context.getShardingItem（）， context.getShardingParameter（），e）;

}

finally{

logger.info（"JobA execute end..."）;

}

}

}

3.4 任務(wù)管理系統(tǒng)的搭建

為方便運(yùn)維管理各個(gè)模塊所有處理海量數(shù)據(jù)的定時(shí)任務(wù)，本系統(tǒng)須搭建運(yùn)維統(tǒng)一管理平臺(tái)Console，該子系統(tǒng)提供可視化界面供運(yùn)維統(tǒng)一管理定時(shí)任務(wù)，通過該系統(tǒng)調(diào)用注冊(cè)中心API，可查看和修改任務(wù)，任務(wù)失敗可重新執(zhí)行，無(wú)須重啟App節(jié)點(diǎn)。該運(yùn)維統(tǒng)一管理平臺(tái)界面如圖2所示。

Console運(yùn)維管理平臺(tái)后端采用Java語(yǔ)言，前端采用HTML、CSS、JS等語(yǔ)言開發(fā)，數(shù)據(jù)庫(kù)采用MySQL8來持久化作業(yè)信息，工程管理工具M(jìn)aven，集成后將其部署到Linux環(huán)境下。

首次搭建Console管理平臺(tái)需設(shè)置全局配置，設(shè)置注冊(cè)中心名稱和地址等信息。啟動(dòng)應(yīng)用后可在Console中查看作業(yè)的運(yùn)行情況。

Console管理平臺(tái)提供服務(wù)器維度和作業(yè)維度查看任務(wù)的功能。服務(wù)器維度可查看接入了Elastic-Job的服務(wù)器IP、進(jìn)程號(hào)、運(yùn)行實(shí)例等信息；作業(yè)維度可查看各個(gè)服務(wù)器的定時(shí)任務(wù)作業(yè)名稱、作業(yè)分片總數(shù)、作業(yè)運(yùn)行的時(shí)間、作業(yè)狀態(tài)等信息。

Console管理平臺(tái)可修改作業(yè)的信息，服務(wù)器維度可將服務(wù)器禁用，停止該服務(wù)器的定時(shí)任務(wù)執(zhí)行，作業(yè)維度可修改作業(yè)信息，如通過cron表達(dá)式修改定時(shí)任務(wù)的執(zhí)行時(shí)間、修改分片總數(shù)、新增自定義參數(shù)等，運(yùn)維工程師只需找到作業(yè)名稱修改其作業(yè)信息即可，修改作業(yè)界面如圖3所示。

Console運(yùn)維管理平臺(tái)還可查看任務(wù)的歷史調(diào)度信息、執(zhí)行參數(shù)和執(zhí)行信息，進(jìn)入Console可查看執(zhí)行日志[5]，清晰地掌握每臺(tái)服務(wù)器定時(shí)任務(wù)的歷史執(zhí)行時(shí)長(zhǎng)、執(zhí)行結(jié)果。

4 結(jié)論

本文重點(diǎn)介紹了Elastic-Job分布式定時(shí)任務(wù)框架的研究并概述了某大型互聯(lián)網(wǎng)應(yīng)用系統(tǒng)上的實(shí)踐，通過使用Elastic-Job解決了互聯(lián)網(wǎng)企業(yè)在大數(shù)據(jù)量定時(shí)任務(wù)作業(yè)中處理效率低、容錯(cuò)性差、任務(wù)管理不方便等問題，同時(shí)保證了系統(tǒng)的高可用性、伸縮性、負(fù)載均衡，并提高了容錯(cuò)性。Elastic-Job框架讓開發(fā)者不再擔(dān)心任務(wù)的線性吞吐量提升等非功能需求，使開發(fā)者能夠更加專注于業(yè)務(wù)編碼設(shè)計(jì)，同時(shí)Elastic-Job可提高運(yùn)維工程師的工作效率，使運(yùn)維不再擔(dān)心任務(wù)的可用性和相關(guān)管理需求，只需通過可視化界面操作相關(guān)App節(jié)點(diǎn)即可輕松管理處理海量數(shù)據(jù)的定時(shí)任務(wù)，從而達(dá)到了自動(dòng)化運(yùn)維的目的。

參考文獻(xiàn)：

[1] 陸穎.基于XXL-JOB的可視化分布式定時(shí)調(diào)度平臺(tái)的設(shè)計(jì)與實(shí)現(xiàn)[J].電腦知識(shí)與技術(shù)， 2023，19（14）：39-41.

[2] 屈洪雪，陳雙，徐海洋.基于Quartz的可視化代理定時(shí)任務(wù)的研究與設(shè)計(jì)[J].電子技術(shù)與軟件工程，2021（18）：44-46.

[3] 鄭祥，顧丹鵬，陳肖勇.基于XXL-JOB的分布式定時(shí)任務(wù)研究和應(yīng)用[J].計(jì)算機(jī)時(shí)代，2002（5）：80-82.

[4] 段詡，張文輝.基于Docker集群的分布式動(dòng)作教學(xué)平臺(tái)設(shè)計(jì)[J].電子設(shè)計(jì)工程，2020，28（23）：63-67，72.

[5] 潘平平.基于松耦合架構(gòu)的分布式定時(shí)任務(wù)調(diào)度系統(tǒng)的設(shè)計(jì)與實(shí)現(xiàn)[D].南京：東南大學(xué)，2020.

【通聯(lián)編輯：王 力】