elastic-job詳解（二）：做業的調度

 

JobScheduler是elastic-job做業調度的關鍵類，也是起始類，在包com.dangdang.ddframe.job.lite.api下。調度任務的執行須要包含兩大步驟：任務的配置和任務的註冊。JobScheduler的構造函數除了任務配置和註冊相關信息以外還有事件和監聽。後二者是elastic-job的擴展功能，咱們後續再介紹。

任務的配置

因爲內部使用quartz做爲任務調度框架，任務的配置的相關的基礎信息也是和quartz一致的。elastic-job的任務配置類在quartz的基礎上（執行方法，cron表達式等）額外封裝了分片策略，監控做業相關參數以及與註冊中心的時間偏差秒數等配置項。

 

任務的註冊

elastic-job是經過zookeeper進行任務協調和故障轉移的，任務的註冊也就是把任務註冊到zookeeper裏面去。任務的註冊包含在任務的啓動過程當中。根節點是項目的名稱，下面一級是任務的名稱。任務一旦建立則不能修改任務的名稱，若是修更名稱將視爲新的任務，建立新的節點。任務名稱節點下又包含5個數據子節點，分別是config, instances, leader, servers和sharding。以下圖：

 

1. config節點：

任務的配置信息，包含執行類，cron表達式，分片算法類，分片數量，分片參數等等。config節點的數據是經過ConfigService持久化到zookeeper中去的。默認狀態下，若是你修改了Job的配置好比cron表達式，分片數量等是不會更新到zookeeper上去的，除非你把參數overwrite修改爲true。

2. instances節點：

同一個Job下的elastic-job的部署實例。一臺機器上能夠啓動多個Job實例，也就是Jar包。instances的命名是IP+@-@+PID。

3. leader節點：

任務實例的主節點信息，經過zookeeper的主節點選舉，選出來的主節點信息。下面的子節點分爲election，sharding和failover三個子節點。分別用於主節點選舉，分片和失效轉移處理。election下面的instance節點顯式了當前主節點的實例ID：jobInstanceId。latch節點也是一個永久節點用於選舉時候的實現分佈式鎖。sharding節點下面有一個臨時節點，necessary，是否須要從新分片的標記。若是分片總數變化，或任務實例節點上下線或啓用/禁用，以及主節點選舉，都會觸發設置重分片標記，主節點會進行分片計算。

4. servers節點：

任務實例的信息，主要是IP地址，任務實例的IP地址。若是多個任務實例在同一臺機器上運行則只會出現一個IP子節點。可在IP地址節點寫入DISABLED表示該任務實例禁用。 在新的cloud native架構下，servers節點大幅弱化，僅包含控制服務器是否能夠禁用這一功能。爲了更加純粹的實現job核心，servers功能將來可能刪除，控制服務器是否禁用的能力應該下放至自動化部署系統。

5. sharding節點：

任務的分片信息，子節點是分片項序號，從零開始，至分片總數減一。分片個個數是在任務配置中設置的。分片項序號的子節點存儲詳細信息。每一個分片項下的子節點用於控制和記錄分片運行狀態。最主要的子節點就是instance。舉例來講，上圖有三個分片，每一個分片下面有個instance的節點，也就說明了這個分片在哪一個instance上運行。如上文所說若是分片總數變化，或任務實例節點上下線或啓用/禁用，以及主節點選舉，都會觸發設置重分片標記，主節點會進行分片計算。分片計算的結果也就體如今這instance上。

 

上文介紹的節點信息並不全面，還有一些會在特定的狀況下出現的臨時節點，更多詳細的介紹能夠請參看官方文檔：http://dangdangdotcom.github.io/elastic-job/elastic-job-lite/03-design/lite-design/

 

任務的啓動

任務的啓動過程，就是任務實例和zookeeper進行交互的過程。每一個實例在啓動過程當中，會把自身的信息註冊到zookeeper中去。並完成選舉和分片策略的設置，也就是完成上文一些zookeeper節點的建立和持久化。

整個啓動的過程都在JobScheduler.init()方法中完成。其中最重要的方法registerStartUpInfo完成了監聽，選舉持久化數據，以及設置分片標誌位（爲了任務執行是主節點進行分片算法）等工做。init()方法中完成了配置和註冊以後，相關的參數被傳遞給了JobScheduleController類，這個類就是quartz的封裝。以前配置的任務執行類和cron表達式被轉換成JobDetail和Trigger這兩個quartz的類，而後經過quartz的scheduler.start觸發任務。等待任務的執行。

總體流程圖以下：

 

 

任務的執行

任務的執行依賴於quartz job的觸發。elastic-job的LiteJob類繼承自quartz的Job類，在任務觸發的時候，添加額外的邏輯處理。LiteJob的執行器AbstractElasticJobExecutor有兩個具體的實現，SimpleJobExecutor和DataflowJobExecutor，各自執行SimpleJob和DataflowJob兩種Job類型。Job觸發的時候，SimpleJobExecutor或者DataflowJobExecutor會被new一次，從新從緩存中加載Job配置並執行。

LiteJob把任務的執行分爲執行前，執行（業務代碼的執行），和執行後三個階段。在執行前階段中主要實現分片策略的執行（shardingIfNecessary方法），記錄事件，執行監聽事件等等。而執行後階段主要處理錯過執行的相關任務以及執行監聽事件。

 

整個執行流程圖以下：