介紹

XXL-JOB是一個輕量級分散式任務排程框架，其核心設計目標是開發迅速、學習簡單、輕量級、易擴充套件。現已開放原始碼並接入多家公司線上產品線，開箱即用。
專案git地址 | 專案首頁

為了方便使用改造，自己在github上fork了一個專案進行完善（地址），新增功能（發簡訊，展示更多欄位、解決部分BUG，新增cron表示式直譯器）

搭建專案、瞭解架構可以在專案官網學習。本文只做加強補充,個人內容通過標註的形式展現。

總體設計

1 原始碼目錄介紹

- /doc :文件資料
- /db :“排程資料庫”建表指令碼
- /xxl-job-admin :排程中心，專案原始碼
- /xxl-job-core :公共Jar依賴
- /xxl-job-executor-samples :執行器，Sample示例專案（大家可以在該專案上進行開發，也可以將現有專案改造生成執行器專案）
 

2 “排程資料庫”配置

XXL-JOB排程模組基於Quartz叢集實現，其“排程資料庫”是在Quartz的11張叢集mysql表基礎上擴充套件而成。

XXL-JOB首先定製了Quartz原生表結構字首（XXL_JOB_QRTZ_）。

然後，在此基礎上新增了幾張張擴充套件表，如下：
- XXL_JOB_QRTZ_TRIGGER_GROUP：執行器資訊表，維護任務執行器資訊；
- XXL_JOB_QRTZ_TRIGGER_REGISTRY：執行器登錄檔，維護線上的執行器和排程中心機器地址資訊；
- XXL_JOB_QRTZ_TRIGGER_INFO：排程擴充套件資訊表： 用於儲存XXL-JOB排程任務的擴充套件資訊，如任務分組、任務名、機器地址、執行器、執行入參和報警郵件等等；
- XXL_JOB_QRTZ_TRIGGER_LOG：排程日誌表： 用於儲存XXL-JOB任務排程的歷史資訊，如排程結果、執行結果、排程入參、排程機器和執行器等等；
- XXL_JOB_QRTZ_TRIGGER_LOGGLUE：任務GLUE日誌：用於儲存GLUE更新歷史，用於支援GLUE的版本回溯功能；

因此，XXL-JOB排程資料庫共計用於16張資料庫表。

主要基於Quartz的資料庫表，如果需要支援其他資料庫，可以到Quartz官網 下載，裡面的文件部分有支援多種型別資料庫（mysql、sqlserver、H2、sybase…）的初始化sql。

3 架構設計

3.1 設計思想

將排程行為抽象形成“排程中心”公共平臺，而平臺自身並不承擔業務邏輯，“排程中心”負責發起排程請求。

將任務抽象成分散的JobHandler，交由“執行器”統一管理，“執行器”負責接收排程請求並執行對應的JobHandler中業務邏輯。

因此，“排程”和“任務”兩部分可以相互解耦，提高系統整體穩定性和擴充套件性；

3.2 系統組成

• 排程模組（排程中心）：
  負責管理排程資訊，按照排程配置發出排程請求，自身不承擔業務程式碼。排程系統與任務解耦，提高了系統可用性和穩定性，同時排程系統性能不再受限於任務模組；
  支援視覺化、簡單且動態的管理排程資訊，包括任務新建，更新，刪除，GLUE開發和任務報警等，所有上述操作都會實時生效，同時支援監控排程結果以及執行日誌，支援執行器Failover。
• 執行模組（執行器）：
  負責接收排程請求並執行任務邏輯。任務模組專注於任務的執行等操作，開發和維護更加簡單和高效；
  接收“排程中心”的執行請求、終止請求和日誌請求等。

3.3 架構圖

4 排程模組剖析

4.1 quartz的不足

Quartz作為開源作業排程中的佼佼者，是作業排程的首選。但是叢集環境中Quartz採用API的方式對任務進行管理，從而可以避免上述問題，但是同樣存在以下問題：

• 問題一：呼叫API的的方式操作任務，不人性化；
• 問題二：需要持久化業務QuartzJobBean到底層資料表中，系統侵入性相當嚴重。
• 問題三：排程邏輯和QuartzJobBean耦合在同一個專案中，這將導致一個問題，在排程任務數量逐漸增多，同時排程任務邏輯逐漸加重的情況加，此時排程系統的效能將大大受限於業務；
• 問題四：quartz底層以“搶佔式”獲取DB鎖並由搶佔成功節點負責執行任務，會導致節點負載懸殊非常大；而XXL-JOB通過執行器實現“協同分配式”執行任務，充分發揮叢集優勢，負載各節點均衡。

XXL-JOB彌補了quartz的上述不足之處。

4.2 RemoteHttpJobBean

常規Quartz的開發，任務邏輯一般維護在QuartzJobBean中，耦合很嚴重。XXL-JOB中“排程模組”和“任務模組”完全解耦，排程模組中的所有排程任務使用同一個QuartzJobBean，即RemoteHttpJobBean。不同的排程任務將各自引數維護在各自擴充套件表資料中，當觸發RemoteHttpJobBean執行時，將會解析不同的任務引數發起遠端呼叫，呼叫各自的遠端執行器服務。

這種呼叫模型類似RPC呼叫，RemoteHttpJobBean提供呼叫代理的功能，而執行器提供遠端服務的功能。

排程器和執行器基於http通訊，通過動態代理的方式實現遠端呼叫。
具體程式碼可見NetComClientProxy，通過重寫FactoryBean<Object> 的getObject()發起遠端呼叫，使用時類似如下程式碼：
ExecutorBiz executorBiz = (ExecutorBiz) new NetComClientProxy(ExecutorBiz.class, "127.0.0.1:9999", null).getObject();
executorBiz.run(triggerParam);

4.3 排程中心HA（叢集）

基於Quartz的叢集方案，資料庫選用Mysql；叢集分散式併發環境中使用QUARTZ定時任務排程，會在各個節點會上報任務，存到資料庫中，執行時會從資料庫中取出觸發器來執行，如果觸發器的名稱和執行時間相同，則只有一個節點去執行此任務。

# for cluster
org.quartz.jobStore.tablePrefix = XXL_JOB_QRTZ_
org.quartz.scheduler.instanceId: AUTO
org.quartz.jobStore.class: org.quartz.impl.jdbcjobstore.JobStoreTX
org.quartz.jobStore.isClustered: true
org.quartz.jobStore.clusterCheckinInterval: 1000

4.4 排程執行緒池

排程採用執行緒池方式實現，避免單執行緒因阻塞而引起任務排程延遲。

org.quartz.threadPool.class: org.quartz.simpl.SimpleThreadPool
org.quartz.threadPool.threadCount: 15
org.quartz.threadPool.threadPriority: 5
org.quartz.threadPool.threadsInheritContextClassLoaderOfInitializingThread: true

XXL-JOB系統中業務邏輯在遠端執行器執行，全非同步化設計，排程中心每次觸發排程時僅傳送一次排程請求，執行器會將請求存入執行佇列並且立即響應排程中心，非同步執行；相比直接在quartz的QuartzJobBean中執行業務邏輯，極大的降低了排程執行緒佔用時間；

XXL-JOB排程中心中每個JOB邏輯非常 “輕”，單個JOB一次執行平均耗時基本在 “10ms” 之內（基本為一次請求的網路開銷）；因此，可以保證使用有限的執行緒支撐大量的JOB併發執行；

理論支撐任務量公式如下：

理論支撐任務量 = 執行緒數配置 / 平均排程頻率（每秒） * 平均觸發耗時（單位s）

理論上採用推薦機器配置 “4核4G記憶體” + “配置1s執行1次密集任務” + “排程中心與執行器ping延遲10ms（0.01s）” 的情況下，

- 單執行緒支撐任務量  ：1 / 1 * 0.01 = 100個任務
- 15個執行緒支撐任務量：15 / 1 * 0.01 = 1500個任務

實際場景中，由於排程中心與執行器ping延遲不同、DB讀寫耗時不同、任務排程密集程度不同，會導致任務量上限會上下波動。

如若需要支撐更多的任務量，可以通過 “調大排程執行緒數” 、”降低排程中心與執行器ping延遲” 和 “提升機器配置” 幾種方式實現。

4.5 @DisallowConcurrentExecution

XXL-JOB排程模組的“排程中心”預設不使用該註解，即預設開啟並行機制，因為RemoteHttpJobBean為公共QuartzJobBean，這樣在多執行緒排程的情況下，排程模組被阻塞的機率很低，大大提高了排程系統的承載量。

XXL-JOB的每個排程任務雖然在排程模組是並行排程執行的，但是任務排程傳遞到任務模組的“執行器”確實序列執行的，同時支援任務終止。

4.6 misfire

錯過了觸發時間，處理規則。
可能原因：服務重啟；排程執行緒被QuartzJobBean阻塞，執行緒被耗盡；某個任務啟用了@DisallowConcurrentExecution，上次排程持續阻塞，下次排程被錯過；

quartz.properties中關於misfire的閥值配置如下，單位毫秒：

org.quartz.jobStore.misfireThreshold: 60000

Misfire規則：
withMisfireHandlingInstructionDoNothing：不觸發立即執行，等待下次排程；
withMisfireHandlingInstructionIgnoreMisfires：以錯過的第一個頻率時間立刻開始執行；
withMisfireHandlingInstructionFireAndProceed：以當前時間為觸發頻率立刻觸發一次執行；

XXL-JOB預設misfire規則為：withMisfireHandlingInstructionDoNothing

CronScheduleBuilder cronScheduleBuilder = CronScheduleBuilder.cronSchedule(jobInfo.getJobCron()).withMisfireHandlingInstructionDoNothing();
CronTrigger cronTrigger = TriggerBuilder.newTrigger().withIdentity(triggerKey).withSchedule(cronScheduleBuilder).build();

4.7 日誌回撥服務

排程模組的“排程中心”作為Web服務部署時，一方面承擔排程中心功能，另一方面也為執行器提供API服務。

排程中心提供的”日誌回撥服務API服務”程式碼位置如下：

xxl-job-admin#com.xxl.job.admin.controller.JobApiController.callback

“執行器”在接收到任務執行請求後，執行任務，在執行結束之後會將執行結果回撥通知“排程中心”：

亦是通過4.2所述的方式進行通訊

4.8 任務HA（Failover）

執行器如若叢集部署，排程中心將會感知到線上的所有執行器，如“127.0.0.1:9997, 127.0.0.1:9998, 127.0.0.1:9999”。

當任務”路由策略”選擇”故障轉移(FAILOVER)”時，當排程中心每次發起排程請求時，會按照順序對執行器發出心跳檢測請求，第一個檢測為存活狀態的執行器將會被選定併發送排程請求。

排程成功後，可在日誌監控介面檢視“排程備註”，如下；

“排程備註”可以看出本地排程執行軌跡，執行器的”註冊方式”、”地址列表”和任務的”路由策略”。”故障轉移(FAILOVER)”路由策略下，排程中心首先對第一個地址進行心跳檢測，心跳失敗因此自動跳過，第二個依然心跳檢測失敗……
直至心跳檢測第三個地址“127.0.0.1:9999”成功，選定為“目標執行器”；然後對“目標執行器”傳送排程請求，排程流程結束，等待執行器回撥執行結果。

4.9 排程日誌

排程中心每次進行任務排程，都會記錄一條任務日誌，任務日誌主要包括以下三部分內容：

• 任務資訊：包括“執行器地址”、“JobHandler”和“執行引數”等屬性，點選任務ID按鈕可檢視，根據這些引數，可以精確的定位任務執行的具體機器和任務程式碼；
• 排程資訊：包括“排程時間”、“排程結果”和“排程日誌”等，根據這些引數，可以瞭解“排程中心”發起排程請求時具體情況。
• 執行資訊：包括“執行時間”、“執行結果”和“執行日誌”等，根據這些引數，可以瞭解在“執行器”端任務執行的具體情況；

排程日誌，針對單次排程，屬性說明如下：
- 執行器地址：任務執行的機器地址；
- JobHandler：Bean模式表示任務執行的JobHandler名稱；
- 任務引數：任務執行的入參；
- 排程時間：排程中心，發起排程的時間；
- 排程結果：排程中心，發起排程的結果，SUCCESS或FAIL；
- 排程備註：排程中心，發起排程的備註資訊，如地址心跳檢測日誌等；
- 執行時間：執行器，任務執行結束後回撥的時間；
- 執行結果：執行器，任務執行的結果，SUCCESS或FAIL；
- 執行備註：執行器，任務執行的備註資訊，如異常日誌等；
- 執行日誌：任務執行過程中，業務程式碼中列印的完整執行日誌，見“4.7 檢視執行日誌”；

4.10 任務依賴

原理：XXL-JOB中每個任務都對應有一個任務ID，同時，每個任務支援設定屬性“子任務ID”，因此，通過“任務ID”可以匹配任務依賴關係。

當父任務執行結束並且執行成功時，將會根據“子任務ID”匹配子任務依賴，如果匹配到子任務，將會主動觸發一次子任務的執行。

在任務日誌介面，點選任務的“執行備註”的“檢視”按鈕，可以看到匹配子任務以及觸發子任務執行的日誌資訊，如無資訊則表示未觸發子任務執行，可參考下圖。

5 任務 “執行模式” 剖析

5.1 “Bean模式” 任務

開發步驟：可參考 “章節三” ；
原理：每個Bean模式任務都是一個Spring的Bean類例項，它被維護在“執行器”專案的Spring容器中。任務類需要加“@JobHandler(value=”名稱”)”註解，因為“執行器”會根據該註解識別Spring容器中的任務。任務類需要繼承統一介面“IJobHandler”，任務邏輯在execute方法中開發，因為“執行器”在接收到排程中心的排程請求時，將會呼叫“IJobHandler”的execute方法，執行任務邏輯。

5.2 “GLUE模式(Java)” 任務

開發步驟：可參考 “章節三” ；
原理：每個 “GLUE模式(Java)” 任務的程式碼，實際上是“一個繼承自“IJobHandler”的實現類的類程式碼”，“執行器”接收到“排程中心”的排程請求時，會通過Groovy類載入器載入此程式碼，例項化成Java物件，同時注入此程式碼中宣告的Spring服務（請確保Glue程式碼中的服務和類引用在“執行器”專案中存在），然後呼叫該物件的execute方法，執行任務邏輯。

5.3 GLUE模式(Shell) + GLUE模式(Python) + GLUE模式(NodeJS)

開發步驟：可參考 “章節三” ；
原理：指令碼任務的原始碼託管在排程中心，指令碼邏輯在執行器執行。當觸發指令碼任務時，執行器會載入指令碼原始碼在執行器機器上生成一份指令碼檔案，然後通過Java程式碼呼叫該指令碼；並且實時將指令碼輸出日誌寫到任務日誌檔案中，從而在排程中心可以實時監控指令碼執行情況；

目前支援的指令碼型別如下：

- shell指令碼：任務執行模式選擇為 "GLUE模式(Shell)"時支援 "shell" 指令碼任務；
- python指令碼：任務執行模式選擇為 "GLUE模式(Python)"時支援 "python" 指令碼任務；
- nodejs指令碼：務執行模式選擇為 "GLUE模式(NodeJS)"時支援 "nodejs" 指令碼任務；

5.4 執行器

執行器實際上是一個內嵌的Jetty伺服器，預設埠9999（配置項：xxl.job.executor.port）。

在專案啟動時，執行器會通過“@JobHandler”識別Spring容器中“Bean模式任務”，以註解的value屬性為key管理起來。

“執行器”接收到“排程中心”的排程請求時，如果任務型別為“Bean模式”，將會匹配Spring容器中的“Bean模式任務”，然後呼叫其execute方法，執行任務邏輯。如果任務型別為“GLUE模式”，將會載入GLue程式碼，例項化Java物件，注入依賴的Spring服務（注意：Glue程式碼中注入的Spring服務，必須存在與該“執行器”專案的Spring容器中），然後呼叫execute方法，執行任務邏輯。

5.5 任務日誌

XXL-JOB會為每次排程請求生成一個單獨的日誌檔案，需要通過 “XxlJobLogger.log” 列印執行日誌，“排程中心”檢視執行日誌時將會載入對應的日誌檔案。

(歷史版本通過重寫LOG4J的Appender實現，存在依賴限制，該方式在新版本已經被拋棄)

日誌檔案存放的位置可在“執行器”配置檔案進行自定義，預設目錄格式為：/data/applogs/xxl-job/jobhandler/“格式化日期”/“資料庫排程日誌記錄的主鍵ID.log”。

在JobHandler中開啟子執行緒時，子執行緒將會將會把日誌列印在父執行緒即JobHandler的執行日誌中，方便日誌追蹤。

6 通訊模組剖析

6.1 一次完整的任務排程通訊流程

- 1、“排程中心”向“執行器”傳送http排程請求: “執行器”中接收請求的服務，實際上是一臺內嵌jetty伺服器，預設埠9999;
- 2、“執行器”執行任務邏輯；
- 3、“執行器”http回撥“排程中心”排程結果: “排程中心”中接收回調的服務，是針對執行器開放一套API服務;

6.2 通訊資料加密

排程中心向執行器傳送的排程請求時使用RequestModel和ResponseModel兩個物件封裝排程請求引數和響應資料, 在進行通訊之前底層會將上述兩個物件物件序列化，並進行資料協議以及時間戳檢驗,從而達到資料加密的功能;

7 任務註冊, 任務自動發現

自v1.5版本之後, 任務取消了”任務執行機器”屬性, 改為通過任務註冊和自動發現的方式, 動態獲取遠端執行器地址並執行。

AppName: 每個執行器機器叢集的唯一標示, 任務註冊以 "執行器" 為最小粒度進行註冊; 每個任務通過其繫結的執行器可感知對應的執行器機器列表;
登錄檔: 見"XXL_JOB_QRTZ_TRIGGER_REGISTRY"表, "執行器" 在進行任務註冊時將會週期性維護一條註冊記錄，即機器地址和AppName的繫結關係; "排程中心" 從而可以動態感知每個AppName線上的機器列表;
執行器註冊: 任務註冊Beat週期預設30s; 執行器以一倍Beat進行執行器註冊, 排程中心以一倍Beat進行動態任務發現; 註冊資訊的失效時間被三倍Beat; 
執行器註冊摘除：執行器銷燬時，將會主動上報排程中心並摘除對應的執行器機器資訊，提高心跳註冊的實時性；

為保證系統”輕量級”並且降低學習部署成本，沒有采用Zookeeper作為註冊中心，採用DB方式進行任務註冊發現；

8 任務執行結果

自v1.6.2之後，任務執行結果通過 “IJobHandler” 的返回值 “ReturnT” 進行判斷；
當返回值符合 “ReturnT.code == ReturnT.SUCCESS_CODE” 時表示任務執行成功，否則表示任務執行失敗，而且可以通過 “ReturnT.msg” 回撥錯誤資訊給排程中心；
從而，在任務邏輯中可以方便的控制任務執行結果；

9 分片廣播 & 動態分片

執行器叢集部署時，任務路由策略選擇”分片廣播”情況下，一次任務排程將會廣播觸發對應叢集中所有執行器執行一次任務，同時傳遞分片引數；可根據分片引數開發分片任務；

“分片廣播” 以執行器為維度進行分片，支援動態擴容執行器叢集從而動態增加分片數量，協同進行業務處理；在進行大資料量業務操作時可顯著提升任務處理能力和速度。

“分片廣播” 和普通任務開發流程一致，不同之處在於可以可以獲取分片引數，獲取分片引數進行分片業務處理。

• Java語言任務獲取分片引數方式：BEAN、GLUE模式(Java)

// 可參考Sample示例執行器中的示例任務"ShardingJobHandler"瞭解試用 
ShardingUtil.ShardingVO shardingVO = ShardingUtil.getShardingVo();

• 指令碼語言任務獲取分片引數方式：GLUE模式(Shell)、GLUE模式(Python)、GLUE模式(Nodejs)

// 指令碼任務入參固定為三個，依次為：任務傳參、分片序號、分片總數。以Shell模式任務為例，獲取分片引數程式碼如下
echo "分片序號 index = $2"
echo "分片總數 total = $3"

分片引數屬性說明：

index：當前分片序號(從0開始)，執行器叢集列表中當前執行器的序號；
total：總分片數，執行器叢集的總機器數量；

該特性適用場景如：
- 1、分片任務場景：10個執行器的叢集來處理10w條資料，每臺機器只需要處理1w條資料，耗時降低10倍；
- 2、廣播任務場景：廣播執行器機器執行shell指令碼、廣播叢集節點進行快取更新等

10 訪問令牌（AccessToken）

為提升系統安全性，排程中心和執行器進行安全性校驗，雙方AccessToken匹配才允許通訊；

排程中心和執行器，可通過配置項 “xxl.job.accessToken” 進行AccessToken的設定。

排程中心和執行器，如果需要正常通訊，只有兩種設定；

• 設定一：排程中心和執行器，均不設定AccessToken；關閉安全性校驗；
• 設定二：排程中心和執行器，設定了相同的AccessToken；

11 排程中心API服務

排程中心提供了API服務，供執行器和業務方選擇使用，目前提供的API服務有：

1、任務結果回撥服務；
2、執行器註冊服務；
3、執行器註冊摘除服務；
4、觸發任務單次執行服務，支援任務根據業務事件觸發；

排程中心API服務位置：com.xxl.job.core.biz.AdminBiz.java

排程中心API服務請求參考程式碼：com.xxl.job.adminbiz.AdminBizTest.java

12 執行器API服務

執行器提供了API服務，供排程中心選擇使用，目前提供的API服務有：

1、心跳檢測
2、忙碌檢測
3、觸發任務執行
4、獲取Rolling Log
5、終止任務

執行器API服務位置：com.xxl.job.core.biz.ExecutorBiz

執行器API服務請求參考程式碼：com.xxl.executor.test.DemoJobHandlerTest

13 故障轉移 & 失敗重試

一次完整任務流程包括”排程（排程中心） + 執行（執行器）”兩個階段。

• “故障轉移”發生在排程階段，在執行器叢集部署時，如果某一臺執行器發生故障，該策略支援自動進行Failover切換到一臺正常的執行器機器並且完成排程請求流程。
• “失敗重試”發生在”排程 + 執行”兩個階段，如下：
  
  • 排程中心排程失敗時，任務失敗處理策略選擇”失敗重試”，將會自動重試一次；
  • 執行器執行失敗時，任務執行結果返回”失敗重試（IJobHandler.FAIL_RETRY）”回撥，將會自動重試一次；

14 執行器灰度上線

排程中心與業務解耦，只需部署一次後常年不需要維護。但是，執行器中託管執行著業務作業，作業上線和變更需要重啟執行器，尤其是Bean模式任務。
執行器重啟可能會中斷執行中的任務。但是，XXL-JOB得益於自建執行器與自建註冊中心，可以通過灰度上線的方式，避免因重啟導致的任務中斷的問題。

步驟如下：
- 1、執行器改為手動註冊，下線一半機器列表（A組），線上執行另一半機器列表（B組）；
- 2、等待A組機器任務執行結束並編譯上線；執行器註冊地址替換為A組；
- 3、等待B組機器任務執行結束並編譯上線；執行器註冊地址替換為A組+B組；
操作結束；

15 任務執行結果說明

系統根據以下標準判斷任務執行結果，可參考之。

–	Bean/Glue(Java)	Glue(Shell) 等指令碼任務
成功	IJobHandler.SUCCESS	0
失敗	IJobHandler.FAIL	-1（其他）
失敗重試	IJobHandler.FAIL_RETRY	101