1.前言

XXL-JOB專(zhuān)題歷史文章列表：

• XXL-JOB調(diào)度中心集群部署配置（一）
• XXL-JOB執(zhí)行器配置及定時(shí)任務(wù)的創(chuàng)建（二）
• XXL-JOB調(diào)度中心對(duì)執(zhí)行器的上下線感知實(shí)現(xiàn)原理（三）

本篇的主要內(nèi)容是XXL-JOB的任務(wù)調(diào)度流程及其實(shí)現(xiàn)原理，包含了兩個(gè)部分：

• 調(diào)度中心如何進(jìn)行任務(wù)調(diào)度
• 執(zhí)行器執(zhí)行任務(wù)需要注意哪些問(wèn)題

在開(kāi)始研究XXL-JOB的調(diào)度流程之前，我們不妨先思考一下，如果讓自己來(lái)實(shí)現(xiàn)一個(gè)任務(wù)調(diào)度，需要從哪些方面去入手呢？

對(duì)調(diào)度流程的思考

在前面的配置相關(guān)的文章中，我們已經(jīng)實(shí)現(xiàn)了一個(gè)調(diào)度中心集群、以及一個(gè)執(zhí)行器，并創(chuàng)建了一個(gè)定時(shí)任務(wù)配置，在這樣的基礎(chǔ)上，要實(shí)現(xiàn)一個(gè)簡(jiǎn)單的任務(wù)調(diào)度Demo是非常簡(jiǎn)單的。

不記得定時(shí)任務(wù)的配置過(guò)程的同學(xué)，可以回顧一下前兩篇關(guān)于調(diào)度中心和執(zhí)行器配置的文章。

• 對(duì)調(diào)度中心來(lái)說(shuō)：
  只需要啟動(dòng)一個(gè)線程，讓這個(gè)線程不斷的去查詢(xún)定時(shí)任務(wù)配置表，拿到配置數(shù)據(jù)之后，與當(dāng)前系統(tǒng)時(shí)間做對(duì)比，判斷任務(wù)是否到了觸發(fā)時(shí)間，如果到了觸發(fā)時(shí)間就調(diào)用執(zhí)行器執(zhí)行定時(shí)任務(wù)。
• 對(duì)執(zhí)行器來(lái)說(shuō)：
  等待調(diào)度中心進(jìn)行任務(wù)調(diào)度，收到調(diào)度請(qǐng)求后執(zhí)行任務(wù)，響應(yīng)執(zhí)行結(jié)果。
  

這樣，一個(gè)最簡(jiǎn)單定時(shí)任務(wù)就完成了。當(dāng)然，這樣的任務(wù)調(diào)度流程是非常粗糙，只能存在于Demo中，想要在生產(chǎn)環(huán)境中運(yùn)行，還需要解決很多問(wèn)題，例如：

調(diào)度中心需要解決的問(wèn)題：

• 調(diào)度中心集群是否會(huì)產(chǎn)生重復(fù)調(diào)度問(wèn)題？
• 間隔多長(zhǎng)時(shí)間查詢(xún)一次數(shù)據(jù)庫(kù)合適？
• 如何判斷任務(wù)已經(jīng)到了觸發(fā)時(shí)間？
• 如果查詢(xún)出的任務(wù)，已經(jīng)過(guò)了觸發(fā)時(shí)間了怎么辦？
• 如何獲取執(zhí)行器？
• 有多個(gè)執(zhí)行器怎么處理呢？
• 任務(wù)執(zhí)行時(shí)間過(guò)長(zhǎng)，阻塞其他任務(wù)執(zhí)行怎么處理？
• ……

執(zhí)行器需要解決的問(wèn)題：

• 如果前一個(gè)任務(wù)沒(méi)有執(zhí)行完，后一個(gè)任務(wù)又來(lái)了，怎么處理？
• 一個(gè)執(zhí)行器中有多個(gè)任務(wù)時(shí)，如何找到當(dāng)前應(yīng)該執(zhí)行的任務(wù)？
• 多個(gè)任務(wù)之間如何避免互相影響？
• 任務(wù)執(zhí)行超時(shí)如何處理？
• ……

后面可以帶著這些問(wèn)題，一起看看XXL-JOB是如何處理的，在看調(diào)度中心的流程之前，先熟悉一下本篇文章中需要用到的幾張表：

xxl_job_registry：執(zhí)行器注冊(cè)表，保存活躍的執(zhí)行器信息
xxl_job_group：執(zhí)行器配置表
xxl_job_info：定時(shí)任務(wù)配置表
xxl_job_lock：分布式鎖信息表

2.調(diào)度中心流程

調(diào)度中心做的第一件事，就是啟動(dòng)一個(gè)線程不斷的掃描定時(shí)任務(wù)配置表 xxl_job_info，我們可以從初始化方法 com.xxl.job.admin.core.scheduler.XxlJobScheduler#init 中找到這個(gè)線程的初始化過(guò)程，如下圖：

可以看到在初始化方法中啟動(dòng)兩個(gè)線程，分別是：

1. scheduleThread：任務(wù)掃描線程，用來(lái)掃描任務(wù)配置表，并判斷當(dāng)前任務(wù)是否應(yīng)該觸發(fā)
2. ringThread：時(shí)間輪線程，除少部分直接觸發(fā)的任務(wù)以外，其余任務(wù)觸發(fā)都由時(shí)間輪線程調(diào)度。

此外，可以注意一下圖中的 5000，這是一個(gè)時(shí)間值，在任務(wù)掃描和處理的過(guò)程中，還會(huì)多次使用到。先看一下任務(wù)配置的掃描細(xì)節(jié)。

2.1.任務(wù)配置掃描流程

scheduleThread啟動(dòng)之后就會(huì)循環(huán)掃描定時(shí)任務(wù)配置表，先看一下代碼：

也就是說(shuō)，每次掃描，會(huì)查詢(xún)xxl_job_info中，處于啟動(dòng)狀態(tài)，且下次執(zhí)行時(shí)間 trigger_next_time <= 當(dāng)前時(shí)間 + 5000ms的數(shù)據(jù)，最多可以獲取到pagesize大小的列表。

這里的 trigger_next_time 指的是下次任務(wù)觸發(fā)時(shí)間，是在定時(shí)任務(wù)配置保存、更新、啟動(dòng)時(shí)，通過(guò)Cron表達(dá)式進(jìn)行計(jì)算的，并且在每次定時(shí)任務(wù)觸發(fā)時(shí)，也會(huì)更新trigger_next_time的值。

為什么不能用系統(tǒng)時(shí)間精確匹配呢？

使用當(dāng)前系統(tǒng)時(shí)間進(jìn)行精確匹配查詢(xún)的話，查詢(xún)出的數(shù)據(jù)是有可能不準(zhǔn)確的。例如：當(dāng)前獲取到的時(shí)間是2022年12月6日18點(diǎn)整，有兩個(gè)定時(shí)任務(wù)的觸發(fā)時(shí)間分別是18:00:00和18:00:01，這時(shí)候可以匹配到第一個(gè)定時(shí)任務(wù)。但是第一個(gè)任務(wù)的調(diào)度時(shí)間大于1s的話，下一次進(jìn)入循環(huán)時(shí)第二個(gè)任務(wù)就匹配不上了。

為了解決這個(gè)問(wèn)題，會(huì)采用將時(shí)間點(diǎn)擴(kuò)大為一個(gè)時(shí)間段的方式，這也就是為什么會(huì)使用 <=當(dāng)前時(shí)間 + 5s 來(lái)作為查詢(xún)條件。

pageSize的值是怎么來(lái)的呢？

這里的pagesize的值是6000，也就是我們經(jīng)常在說(shuō)的，XXL-JOB默認(rèn)支持定時(shí)任務(wù)數(shù)量，這是通過(guò)一個(gè)公式在進(jìn)行計(jì)算的。

經(jīng)過(guò)作者大量的數(shù)據(jù)驗(yàn)證，發(fā)現(xiàn)大多數(shù)定時(shí)任務(wù)的觸發(fā)耗時(shí)都在 50ms 以?xún)?nèi)，可以得到qps為 20。
在xxl-job-admin的配置文件中，有這么兩個(gè)默認(rèn)配置：

xxl.job.triggerpool.fast.max=200
xxl.job.triggerpool.slow.max=100

即觸發(fā)線程池中的線程一共有300個(gè)，所以理論上每秒能處理的觸發(fā)任務(wù)就是(200+100)×20=6000個(gè)，實(shí)際能處理多少還得看硬件配置。

注：這里的fast和slow指的是快慢線程池，下面的內(nèi)容會(huì)講到。

如果多部署幾個(gè)調(diào)度中心的節(jié)點(diǎn)，可以增加可用的任務(wù)配置數(shù)量嗎？

很遺憾，并不能，為了避免調(diào)度中心集群重復(fù)調(diào)度的問(wèn)題，使用數(shù)據(jù)庫(kù)做了一個(gè)分布式鎖，在每個(gè)調(diào)度中心的scheduleThread在掃描任務(wù)表之前，都會(huì)先執(zhí)行下面的SQL語(yǔ)句

select * from xxl_job_lock where lock_name = 'schedule_lock' for update;

for update語(yǔ)法會(huì)給lock_name = schedule_lock的數(shù)據(jù)加上行鎖，這是一個(gè)獨(dú)占鎖，所以，不管部署多少個(gè)節(jié)點(diǎn)，同一時(shí)間只可能有一個(gè)線程可以查出數(shù)據(jù)，其他線程都會(huì)被阻塞。

間隔多長(zhǎng)時(shí)間查詢(xún)一次數(shù)據(jù)庫(kù)合適？

不間斷的循環(huán)查詢(xún)數(shù)據(jù)庫(kù)可能會(huì)導(dǎo)致大量出現(xiàn)無(wú)效的查詢(xún)（例如：每次都查不到結(jié)果，但還是一直查），這不是一種很好的方式，一般我們?cè)谘h(huán)掃描數(shù)據(jù)庫(kù)時(shí)，都會(huì)加上一個(gè)間隔時(shí)間。
XXL-JOB對(duì)間隔時(shí)間的定義分別是，1s 和 5s，我們先看一下實(shí)現(xiàn)的代碼：

圖中的preReadSuc：是一個(gè)boolean值，當(dāng)有查詢(xún)出了可調(diào)度的定時(shí)任務(wù)時(shí)，值為true，反之為false。
也就是說(shuō)，如果執(zhí)行了調(diào)度且調(diào)度時(shí)間小于1s時(shí)，就會(huì)等待1s再執(zhí)行下一次循環(huán)，如果沒(méi)有執(zhí)行調(diào)度，則等待5s。至于為什么是5s，是因?yàn)樵诓樵?xún)出定時(shí)任務(wù)配置后，還通過(guò)5s這個(gè)時(shí)間段，做了一個(gè)觸發(fā)時(shí)機(jī)的判斷，達(dá)到一個(gè)既不影響任務(wù)觸發(fā)，又能降低數(shù)據(jù)庫(kù)查詢(xún)次數(shù)的平衡。
圖中還有一個(gè)System.currentTimeMillis() % 1000，猜測(cè)這個(gè)代碼的目的是讓不同節(jié)點(diǎn)的睡眠時(shí)間分散一點(diǎn)，避免集中觸發(fā)。

現(xiàn)在已經(jīng)查詢(xún)出了定時(shí)任務(wù)列表，由查詢(xún)方式?jīng)Q定了不是列表中的每個(gè)任務(wù)都應(yīng)該觸發(fā)，所以對(duì)查詢(xún)出的列表還需要做一次觸發(fā)時(shí)機(jī)的計(jì)算。

2.2.計(jì)算任務(wù)觸發(fā)時(shí)機(jī)

在任務(wù)觸發(fā)時(shí)機(jī)的計(jì)算中，還會(huì)用到常量PRE_READ_MS，通過(guò)這個(gè)常量的值5s，XXL-JOB將查詢(xún)出的任務(wù)列表數(shù)據(jù)劃分為三個(gè)部分：

• 已超時(shí)5s以上
• 已超時(shí)但不足5s
• 還未到觸發(fā)時(shí)間

由于當(dāng)前時(shí)間nowTime已經(jīng)固定，而每個(gè)任務(wù)的觸發(fā)時(shí)間可能會(huì)不一樣，以觸發(fā)時(shí)間來(lái)做一個(gè)時(shí)間軸，就可以用圖示直觀的表示這三個(gè)部分的數(shù)據(jù)，如下圖：

這里的觸發(fā)時(shí)間，就是上面提到的 xxl_job_info 表中 trigger_next_time 字段值，接下來(lái)可以看看這幾個(gè)部分，分別做了什么處理。

2.2.1.已超時(shí)5秒以上

圖中的代碼塊對(duì)應(yīng)就是已超時(shí)5秒以上的數(shù)據(jù)，if條件轉(zhuǎn)換一下就是now - 5s > 觸發(fā)時(shí)間。
其中最關(guān)鍵的就是調(diào)度過(guò)期策略的配置，還記得在管理后臺(tái)如何配置任務(wù)的嗎？

這里有有兩種不同的執(zhí)行流程，默認(rèn)情況下的調(diào)度過(guò)期策略是忽略，已經(jīng)超時(shí)5秒以上的任務(wù)會(huì)被丟棄掉，另外一種策略是立即執(zhí)行一次，就是字面意思，立即觸發(fā)一次任務(wù)調(diào)度。
此外，trigger方法和refreshNextValidTime方法分別對(duì)應(yīng)任務(wù)觸發(fā)和更新下次觸發(fā)時(shí)間，在另外兩個(gè)部分還會(huì)使用到。

2.2.2.超時(shí)未超過(guò)5秒

按照當(dāng)前對(duì)數(shù)據(jù)庫(kù)的查詢(xún)方式，這部分定時(shí)任務(wù)就是最應(yīng)該直接觸發(fā)的，此處會(huì)立即觸發(fā)一次，并更新下次觸發(fā)時(shí)間。此外，如果發(fā)現(xiàn)在5秒內(nèi)會(huì)再次觸發(fā)，還會(huì)將這個(gè)任務(wù)直接放入到時(shí)間輪中，由時(shí)間輪來(lái)進(jìn)行下一次調(diào)度。

2.2.3.還未到觸發(fā)時(shí)間

可以看到這個(gè)代碼和上面放入時(shí)間輪的代碼一模一樣，都是將未來(lái)5s會(huì)觸發(fā)的定時(shí)任務(wù)放入到了時(shí)間輪中，本篇到現(xiàn)在已經(jīng)多次提到了時(shí)間輪，它到底是個(gè)什么東西呢？
接下來(lái)就簡(jiǎn)單聊一下XXL-JOB中使用的時(shí)間輪。

時(shí)間輪是一種用于實(shí)現(xiàn)定時(shí)器、延時(shí)調(diào)度等功能的算法，廣泛的運(yùn)用于各種中間件中，例如：Netty、Kafka、Dubbo等，在XXL-JOB中，實(shí)現(xiàn)方式非常簡(jiǎn)單，通過(guò)一個(gè)HashMap來(lái)實(shí)現(xiàn)的，具體的做法是：
先獲取到triggerNextTime的值，這是一個(gè)時(shí)間戳，通過(guò)下面的算法可以獲取到這個(gè)時(shí)間戳對(duì)應(yīng)的秒數(shù)，在0-59之間。

// [0,59]
int ringSecond = (int) ((jobInfo.getTriggerNextTime() / 1000) % 60);

然后 以 ringSecond 為key，jobId(任務(wù)Id)為value，put到HashMap中。

private volatile static Map<Integer, List<Integer>> ringData = new ConcurrentHashMap<>();

 private void pushTimeRing(int ringSecond, int jobId){
    List<Integer> ringItemData = ringData.get(ringSecond);
    if (ringItemData == null) {
        ringItemData = new ArrayList<Integer>();
        ringData.put(ringSecond, ringItemData);
    }
    ringItemData.add(jobId);
}

下面是從百度圖片中找到的一張時(shí)間輪的圖片，這張圖片很形象的展示了時(shí)間輪的數(shù)據(jù)結(jié)構(gòu)。

圖中的數(shù)組代表的是秒數(shù)，鏈表代表的是這一秒鐘有多少任務(wù)需要執(zhí)行。
剝開(kāi)時(shí)間輪神秘的面紗，其實(shí)實(shí)現(xiàn)起來(lái)非常的簡(jiǎn)單，當(dāng)然XXL-JOB中的時(shí)間輪算法只是一種最簡(jiǎn)單的運(yùn)用，由于本篇并不是在講時(shí)間輪算法，如果想詳細(xì)的了解時(shí)間輪算法，可以百度一下，有非常多的資料。

接下來(lái)就該時(shí)間輪線程登場(chǎng)了，即ringThread，除了上述的兩種在scheduleThread直接觸發(fā)的任務(wù)外，其他的任務(wù)都是通過(guò)時(shí)間輪線程來(lái)觸發(fā)的，下面為實(shí)現(xiàn)代碼：

先獲取到當(dāng)前時(shí)間的秒數(shù)，然后從時(shí)間輪中取出當(dāng)前秒和前一秒的所有任務(wù)，循環(huán)ringItemData，依次觸發(fā)其中的每一個(gè)任務(wù)。為什么需要獲取前一秒的數(shù)據(jù)，作者在注釋中已經(jīng)解釋了，就不多做贅述了。

至此，定時(shí)任務(wù)的查詢(xún)和觸發(fā)時(shí)機(jī)的計(jì)算過(guò)程就完結(jié)了，下面一張這部分的流程圖。

2.3.任務(wù)觸發(fā)流程

在上面的代碼中，我們看到JobTriggerPoolHelper.trigger()一共出現(xiàn)了3次，把這三次調(diào)用放在一起對(duì)比一下：

JobTriggerPoolHelper.trigger(jobInfo.getId(), TriggerTypeEnum.MISFIRE, -1, null, null, null);
JobTriggerPoolHelper.trigger(jobInfo.getId(), TriggerTypeEnum.CRON, -1, null, null, null);
JobTriggerPoolHelper.trigger(jobId, TriggerTypeEnum.CRON, -1, null, null, null);        

可以看到，在任務(wù)調(diào)度的流程中，只需要關(guān)注3個(gè)關(guān)鍵字段：

• jobId：定時(shí)任務(wù)配置id，用于查詢(xún)定時(shí)任務(wù)配置。
• triggerType：定時(shí)任務(wù)的觸發(fā)類(lèi)型，用于記錄日志。
• failRetryCount：失敗重試次數(shù)，這里傳入-1，表示使用定時(shí)任務(wù)配置中的重試次數(shù)。

這行代碼的意思就是將應(yīng)該觸發(fā)的定時(shí)任務(wù)，放入任務(wù)觸發(fā)線程池中。

后面三個(gè)參數(shù)會(huì)在什么時(shí)候用到呢？
我們配置的定時(shí)任務(wù)，除了等待到指定時(shí)間觸發(fā)以外，有時(shí)候也需要手動(dòng)觸發(fā)，在管理后臺(tái)提供了任務(wù)的手動(dòng)觸發(fā)功能。

圖中的任務(wù)參數(shù) 和 機(jī)器地址對(duì)應(yīng)的就是參數(shù)列表中的executorParam和addressList。剩下的executorShardingParam要特殊一點(diǎn)，只有在使用分片廣播這個(gè)路由策略，且失敗重試次數(shù)大于0時(shí)才有可能使用到。

參數(shù)是由這個(gè)路由策略生成的，并在發(fā)起調(diào)度請(qǐng)求時(shí)保存到任務(wù)日志中，重試的時(shí)候會(huì)查詢(xún)出來(lái)使用。

2.3.1.任務(wù)觸發(fā)線程池

觸發(fā)線程池其實(shí)在前面已經(jīng)提到過(guò)了，有兩種線程池fastTriggerPool與slowTriggerPool，初始化的方式也非常簡(jiǎn)單，就是按照配置文件中配置的線程池大小創(chuàng)建線程池就OK了。

為什么會(huì)有快慢兩種線程池呢？

主要是為了做一個(gè)線程池的隔離，將正常執(zhí)行的任務(wù)放入到fastTriggerPool中，將執(zhí)行偏慢的任務(wù)放到slowTriggerPool中，避免執(zhí)行較慢的任務(wù)占用過(guò)多資源，影響到了其他正常任務(wù)的調(diào)度。

什么樣的任務(wù)算作是慢任務(wù)？

在程序中使用ConcurrentHashMap維護(hù)了一個(gè)計(jì)數(shù)器，key為jobId，value為超時(shí)次數(shù)，當(dāng)任務(wù)觸發(fā)時(shí)間超過(guò)500ms時(shí)，超時(shí)次數(shù) + 1，同一個(gè)任務(wù)在1分鐘內(nèi)超時(shí)超過(guò)了10次，這個(gè)任務(wù)就會(huì)被定義為慢任務(wù)，后續(xù)就會(huì)由slowTriggerPool來(lái)進(jìn)行調(diào)度。
后續(xù)通過(guò)helper.addTrigger，就會(huì)從線程池中獲取一個(gè)線程，執(zhí)行任務(wù)觸發(fā)操作，在做實(shí)際的觸發(fā)操作之前，還需要處理一下傳入的參數(shù)。

2.3.2.參數(shù)處理

這個(gè)步驟的代碼很多，這里就不大篇幅的貼代碼截圖了，通過(guò)文件描述的形式，來(lái)描述一下流程。

第一步：使用jobId查詢(xún)出數(shù)據(jù)庫(kù)中的定時(shí)任務(wù)配置，后續(xù)的流程以此為基礎(chǔ)。
第二步：如果傳入的執(zhí)行參數(shù)executorParam，則優(yōu)先使用傳入的，反之使用任務(wù)配置中的參數(shù)。
第三步：計(jì)算失敗重試次數(shù)，如果傳入的是-1，則使用任務(wù)配置中的失敗重試次數(shù)。
finalFailRetryCount = failRetryCount >= 0 ? failRetryCount : jobInfo.getExecutorFailRetryCount();
第四步：如果傳入了執(zhí)行器地址，則以傳入的為準(zhǔn)，反之使用注冊(cè)中心中的執(zhí)行器地址。
第五步：如果傳入了分片參數(shù)executorShardingParam則直接使用。

參數(shù)處理完成之后就會(huì)進(jìn)入到執(zhí)行流程，在執(zhí)行流程中分片廣播這個(gè)特殊的路由策略會(huì)做特殊的處理，如果是這個(gè)策略，會(huì)將注冊(cè)中心中，同一個(gè)定時(shí)任務(wù)對(duì)應(yīng)的所有執(zhí)行器節(jié)點(diǎn)都調(diào)用一遍，我們可以后面再聊這個(gè)策略，先看非分片廣播策略的處理方式。

2.3.3.任務(wù)觸發(fā)

這一步是對(duì)執(zhí)行器的實(shí)際調(diào)用方法，有兩個(gè)需要注意的點(diǎn)：阻塞策略 和 路由策略的處理。
先說(shuō)阻塞策略，XXL-JOB提供的阻塞策略一共有三種：

這里會(huì)獲取到任務(wù)配置中的阻塞策略，封裝到調(diào)用參數(shù)中發(fā)送給執(zhí)行器，執(zhí)行器會(huì)按照傳入的策略進(jìn)行處理，這個(gè)在下面的執(zhí)行器部分會(huì)詳聊。
至于路由策略，當(dāng)執(zhí)行器部署為集群節(jié)點(diǎn)時(shí)，才會(huì)發(fā)揮作用，XXL-JOB提供了如下路由策略：

除了分片廣播外，其他路由的作用，都是從執(zhí)行器的集群節(jié)點(diǎn)中，獲取其中一個(gè)節(jié)點(diǎn)來(lái)進(jìn)行調(diào)用，通過(guò)下面的接口發(fā)起HTTP請(qǐng)求。

最后，會(huì)收到執(zhí)行器響應(yīng)的調(diào)用結(jié)果，保存到日志表中。

2.3.4.分片廣播策略（補(bǔ)充）

用一張圖來(lái)描述分片廣播：

調(diào)度中心會(huì)向當(dāng)前任務(wù)的所有執(zhí)行器節(jié)點(diǎn)都發(fā)起一個(gè)調(diào)度請(qǐng)求，并且?guī)戏制瑓?shù)。執(zhí)行器在收到請(qǐng)求之后，可以通過(guò)index的值，以不同index的值來(lái)做分片策略。
在官方示例中，有分片廣播的用法，可以參考：

至此，調(diào)度中心的調(diào)度流程就已經(jīng)結(jié)束了，流程圖更新為：

接下來(lái)就等待執(zhí)行器回調(diào)，獲取任務(wù)執(zhí)行結(jié)果。

3.執(zhí)行器流程

由于本系列文章中的相關(guān)配置都是以SpringBoot為基礎(chǔ)來(lái)創(chuàng)建的，所以這里只分析Bean模式的執(zhí)行器。當(dāng)執(zhí)行器通過(guò)NettyServer收到調(diào)度請(qǐng)求后，會(huì)通過(guò)調(diào)度請(qǐng)求中傳入的參數(shù)executorHandler來(lái)選擇任務(wù)處理器。

什么是任務(wù)處理器呢？
就是實(shí)際執(zhí)行任務(wù)的方法，我們創(chuàng)建一個(gè)定時(shí)任務(wù)需要在兩處配置任務(wù)處理器：管理后臺(tái) 和方法注解，兩處填寫(xiě)一樣的處理器名稱(chēng)。

一般情況下，方法使用注解標(biāo)注后，都會(huì)在服務(wù)啟動(dòng)的時(shí)候?qū)⒆⒔庑畔⒓泄芾砥饋?lái)，例如這里就會(huì)將@XxlJob的注解信息，及其所在的Bean和Method存入一個(gè)CurrentHashMap中。

3.1.任務(wù)處理器初始化

Spring提供了一個(gè)擴(kuò)展點(diǎn)，在bean對(duì)象初始化完成之后，做一些額外的操作，這里只需要實(shí)現(xiàn)SmartInitializingSingleton的接口afterSingletonsInstantiated方法，然后在這個(gè)方法中，掃描每一個(gè)bean對(duì)象，找到被@XxlJob標(biāo)記的方法，就可以獲取到每一個(gè)任務(wù)處理器與它所在的bean對(duì)象、方法之間的對(duì)應(yīng)關(guān)系。

以上圖中的demoJobHandler為例，初始化流程會(huì)先將sampleXxlJob對(duì)象與demoJobHandler方法封裝到一個(gè)實(shí)體對(duì)象MethodJobHandler中。

然后，以@XxlJob注解中的value為key,MethodJobHandler為value，保存到Map中

在任務(wù)處理的流程中，只需以調(diào)度請(qǐng)求中的任務(wù)處理器參數(shù)為key，就可以獲取到任務(wù)處理器對(duì)象了。

3.2.執(zhí)行器任務(wù)處理流程

XXL-JOB給每一個(gè)任務(wù)處理器都分配了一個(gè)單獨(dú)的線程來(lái)做任務(wù)處理，這么做的好處是，任務(wù)之間是隔離的，互不影響。之所以可以這么做，是因?yàn)榧軜?gòu)設(shè)計(jì)中將定時(shí)任務(wù)執(zhí)行器內(nèi)聚到每個(gè)業(yè)務(wù)中，從而一個(gè)服務(wù)所需要的定時(shí)任務(wù)數(shù)量（線程數(shù)）并不會(huì)太多。
同時(shí)，還給每個(gè)定時(shí)任務(wù)都提供了一個(gè)隊(duì)列，用于處理那種 前一個(gè)任務(wù)還沒(méi)執(zhí)行完，后一個(gè)任務(wù)又被調(diào)度過(guò)來(lái)了 的情況。
就是下圖中的結(jié)構(gòu)：

3.2.1.jobThread創(chuàng)建

和jobHandler不一樣的是，jobThread不是在執(zhí)行器初始化的時(shí)候創(chuàng)建的，而是在執(zhí)行器接收到調(diào)度請(qǐng)求時(shí)，判斷當(dāng)前jobId有沒(méi)有已經(jīng)生成的jobThread，如果沒(méi)有則會(huì)創(chuàng)建一個(gè)放入CurrentHashMap中。
之所以使用這個(gè)即時(shí)創(chuàng)建的方式，是因?yàn)槲覀冇锌赡軙?huì)在后臺(tái)配置中切換運(yùn)行模式：

每種運(yùn)行模式切換后對(duì)用的jobHandler是不一樣的，所以jobThread也需要重新生成。

3.2.2.阻塞策略判斷

XXL-JOB提供了三種阻塞策略，分別是：

• 單機(jī)串行：前一個(gè)任務(wù)還沒(méi)有執(zhí)行完畢，就等前一個(gè)任務(wù)執(zhí)行完再執(zhí)行當(dāng)次的任務(wù)
• 丟棄后續(xù)調(diào)度：前一個(gè)任務(wù)沒(méi)有執(zhí)行完畢，就終止當(dāng)次任務(wù)。
• 覆蓋之前調(diào)度：不管前一個(gè)任務(wù)有沒(méi)有執(zhí)行完畢，都直接執(zhí)行當(dāng)次任務(wù)。

需要注意的是，當(dāng)前定時(shí)任務(wù)是第一次被調(diào)度時(shí)，不會(huì)觸發(fā)阻塞策略，其實(shí)也很好理解，第一次被調(diào)用時(shí)，會(huì)創(chuàng)建一個(gè)新的jobThread，triggerQueue里面肯定是空的，就沒(méi)有觸發(fā)阻塞策略的必要。
對(duì)于三種策略的實(shí)現(xiàn)方式，也很簡(jiǎn)單：

• 單機(jī)串行：將當(dāng)次請(qǐng)求直接push到triggerQueue中。
• 丟棄后續(xù)調(diào)度：如果triggerQueue中還有正在執(zhí)行的任務(wù)，則不將本次請(qǐng)求放入到隊(duì)列中。
• 覆蓋之前調(diào)度：重新創(chuàng)建一個(gè)jobThread執(zhí)行任務(wù)，先前的線程會(huì)在執(zhí)行完畢后，被下一次GC回收。

3.2.3.任務(wù)執(zhí)行

triggerQueue的類(lèi)型是LinkedBlockingQueue，是一種阻塞隊(duì)列，根據(jù)阻塞隊(duì)列的特性，使用poll()方法獲取隊(duì)列頭的任務(wù)，如果隊(duì)列為空后，當(dāng)前線程會(huì)被阻塞，直到有新的任務(wù)push到隊(duì)列中才會(huì)喚醒線程。
所以，只需要在jobThread的run()方法中，通過(guò)一個(gè)循環(huán)來(lái)獲取隊(duì)列中的任務(wù)即可。

獲取到triggerParam，表示有新的調(diào)度請(qǐng)求，這時(shí)候會(huì)先通過(guò)triggerParam中的值，打印一個(gè)請(qǐng)求日志，然后請(qǐng)求就會(huì)通過(guò)jobThread中引用的jobHandler執(zhí)行方法的調(diào)用。

可以看到，是一個(gè)很常見(jiàn)的方法反射調(diào)用方式。
triggerParam還有其他的作用嗎？
我們?cè)诠芾砗竺鎰?chuàng)建定時(shí)任務(wù)的時(shí)候，有一個(gè)超時(shí)時(shí)間的配置：

如果這個(gè)配置有值的話，就不會(huì)直接使用當(dāng)前線程來(lái)執(zhí)行方法調(diào)用，而是通過(guò)一個(gè)futureTask來(lái)做異步調(diào)用，在get()方法中傳入超時(shí)時(shí)間，如果超過(guò)了配置的超時(shí)時(shí)間都沒(méi)有收到返回值，則會(huì)拋出TimeoutException。外層業(yè)務(wù)捕獲超時(shí)異常后，會(huì)將超時(shí)信息封裝到上下文中，供后續(xù)回調(diào)流程使用。

3.3.任務(wù)回調(diào)流程

回調(diào)流程也是異步處理的，不管任務(wù)是否執(zhí)行成功，最終都將上下文信息xxlJobContext被push到回調(diào)隊(duì)列callBackQueue中，回調(diào)線程triggerCallbackThread會(huì)從隊(duì)列中獲取到回調(diào)信息，通過(guò)callback方法回調(diào)調(diào)度中心，這個(gè)流程與上面的任務(wù)執(zhí)行流程是非常類(lèi)似的，它們的區(qū)別在于回調(diào)線程對(duì)象是單例的，只會(huì)存在一個(gè)（想想為什么）。
執(zhí)行器最終會(huì)調(diào)用回調(diào)的Http接口，將信息傳回調(diào)度中心。

調(diào)度中心在獲取到回到的信息之后，通過(guò)callbackThreadPool對(duì)回調(diào)請(qǐng)求做異步處理，更新日志中的調(diào)用結(jié)果。（所以執(zhí)行器的回調(diào)線程只做了一個(gè)遠(yuǎn)程調(diào)用操作，不等待后續(xù)流程，一個(gè)完全夠用了）。

至此，一次任務(wù)調(diào)度觸發(fā)定時(shí)任務(wù)執(zhí)行的流程就結(jié)束了。

4.結(jié)語(yǔ)

現(xiàn)在再回想一下開(kāi)篇提出的那些問(wèn)題，是否已經(jīng)有了答案了呢？嘗試一下回答吧。

調(diào)度中心需要解決的問(wèn)題：

• 調(diào)度中心集群是否會(huì)產(chǎn)生重復(fù)調(diào)度問(wèn)題？
• 間隔多長(zhǎng)時(shí)間查詢(xún)一次數(shù)據(jù)庫(kù)合適？
• 如何判斷任務(wù)已經(jīng)到了觸發(fā)時(shí)間？
• 如果查詢(xún)出的任務(wù)，已經(jīng)過(guò)了觸發(fā)時(shí)間了怎么辦？
• 如何獲取執(zhí)行器？
• 有多個(gè)執(zhí)行器怎么處理呢？
• 任務(wù)執(zhí)行時(shí)間過(guò)長(zhǎng)，阻塞其他任務(wù)執(zhí)行怎么處理？
• ……

執(zhí)行器需要解決的問(wèn)題：

• 如果前一個(gè)任務(wù)沒(méi)有執(zhí)行完，后一個(gè)任務(wù)又來(lái)了，怎么處理？
• 一個(gè)執(zhí)行器中有多個(gè)任務(wù)時(shí)，如何找到當(dāng)前應(yīng)該執(zhí)行的任務(wù)？
• 多個(gè)任務(wù)之間如何避免互相影響？
• 任務(wù)執(zhí)行超時(shí)如何處理？
• ……

異步實(shí)踐
XXL-JOB的調(diào)度流程中使用了大量的異步用法，總結(jié)起來(lái)就是兩種：

• 通過(guò)線程池來(lái)執(zhí)行異步操作
• 通過(guò)自旋線程 + 阻塞隊(duì)列的方式來(lái)執(zhí)行異步操作

源碼中對(duì)多線程的使用方式是一種非常好的示例，我們完全可以參照這里的源碼，在自己的項(xiàng)目里面實(shí)現(xiàn)異步調(diào)度。
調(diào)度流程
XXL-JOB調(diào)度流程的思想是比較容易理解的，整個(gè)流程看起來(lái)很舒服。

• 獲取任務(wù)：調(diào)度線程不斷的掃描任務(wù)表，查詢(xún)出將要執(zhí)行的任務(wù)。
• 前置處理：對(duì)每一個(gè)任務(wù)都做一次觸發(fā)時(shí)間的計(jì)算，能夠立即觸發(fā)的就立即觸發(fā)，不能立即觸發(fā)的就放在時(shí)間輪中觸發(fā)，不能觸發(fā)的就拋棄掉。
• 路由策略：在執(zhí)行器集群中選擇一個(gè)節(jié)點(diǎn)執(zhí)行定時(shí)任務(wù)。
• 觸發(fā)任務(wù)：調(diào)度線程不斷的從時(shí)間輪中獲取任務(wù)并觸發(fā)。
• 異步調(diào)度：調(diào)度中心將調(diào)度與觸發(fā)做了異步處理，使用觸發(fā)線程池來(lái)做Http調(diào)用。
• 阻塞策略：根據(jù)阻塞策略判斷當(dāng)前的調(diào)用請(qǐng)求是否執(zhí)行。
• 任務(wù)執(zhí)行：執(zhí)行器為每個(gè)任務(wù)都分配了一個(gè)線程，自己處理自己的任務(wù)，任務(wù)之間不會(huì)互相影響。
• 任務(wù)回調(diào)：將執(zhí)行結(jié)果回傳到調(diào)度中心中，更新任務(wù)執(zhí)行狀態(tài)。

最后，再附上一張完整的流程圖：

如果覺(jué)得本文對(duì)你有所幫助，可以幫忙點(diǎn)點(diǎn)贊哦！你的支持是我更新最大的動(dòng)力！文章來(lái)源地址http://www.zghlxwxcb.cn/news/detail-565151.html

到了這里，關(guān)于【分布式任務(wù)調(diào)度】XXL-JOB的任務(wù)調(diào)度實(shí)現(xiàn)原理（四）的文章就介紹完了。如果您還想了解更多內(nèi)容，請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！