配置屬性詳細說明：
基礎配置：- 執行器：任務的綁定的執行器，任務觸發調度時將會自動發現注冊成功的執行器, 實現任務自動發現功能; 另一方面也可以方便的進行任務分組。每個任務必須綁定一個執行器, 可在 "執行器管理" 進行設置;- 任務描述：任務的描述信息，便於任務管理；- 負責人：任務的負責人；- 報警郵件：任務調度失敗時郵件通知的郵箱地址，支持配置多郵箱地址，配置多個郵箱地址時用逗號分隔；觸發配置：- 調度類型：無：該類型不會主動觸發調度；CRON：該類型將會通過CRON，觸發任務調度；固定速度：該類型將會以固定速度，觸發任務調度；按照固定的間隔時間，周期性觸發；固定延遲：該類型將會以固定延遲，觸發任務調度；按照固定的延遲時間，從上次調度結束后開始計算延遲時間，到達延遲時間后觸發下次調度；- CRON：觸發任務執行的Cron表達式；- 固定速度：固件速度的時間間隔，單位為秒；- 固定延遲：固件延遲的時間間隔，單位為秒；任務配置：- 運行模式：BEAN模式：任務以JobHandler方式維護在執行器端；需要結合 "JobHandler" 屬性匹配執行器中任務；GLUE模式(Java)：任務以源碼方式維護在調度中心；該模式的任務實際上是一段繼承自IJobHandler的Java類代碼並 "groovy" 源碼方式維護，它在執行器項目中運行，可使用@Resource/@Autowire注入執行器里中的其他服務；GLUE模式(Shell)：任務以源碼方式維護在調度中心；該模式的任務實際上是一段 "shell" 腳本；GLUE模式(Python)：任務以源碼方式維護在調度中心；該模式的任務實際上是一段 "python" 腳本；GLUE模式(PHP)：任務以源碼方式維護在調度中心；該模式的任務實際上是一段 "php" 腳本；GLUE模式(NodeJS)：任務以源碼方式維護在調度中心；該模式的任務實際上是一段 "nodejs" 腳本；GLUE模式(PowerShell)：任務以源碼方式維護在調度中心；該模式的任務實際上是一段 "PowerShell" 腳本；- JobHandler：運行模式為 "BEAN模式" 時生效，對應執行器中新開發的JobHandler類“@JobHandler”注解自定義的value值；- 執行參數：任務執行所需的參數；高級配置：- 路由策略：當執行器集群部署時，提供豐富的路由策略，包括；FIRST（第一個）：固定選擇第一個機器；LAST（最后一個）：固定選擇最后一個機器；ROUND（輪詢）：；RANDOM（隨機）：隨機選擇在線的機器；CONSISTENT_HASH（一致性HASH）：每個任務按照Hash算法固定選擇某一台機器，且所有任務均勻散列在不同機器上。LEAST_FREQUENTLY_USED（最不經常使用）：使用頻率最低的機器優先被選舉；LEAST_RECENTLY_USED（最近最久未使用）：最久未使用的機器優先被選舉；FAILOVER（故障轉移）：按照順序依次進行心跳檢測，第一個心跳檢測成功的機器選定為目標執行器並發起調度；BUSYOVER（忙碌轉移）：按照順序依次進行空閑檢測，第一個空閑檢測成功的機器選定為目標執行器並發起調度；SHARDING_BROADCAST(分片廣播)：廣播觸發對應集群中所有機器執行一次任務，同時系統自動傳遞分片參數；可根據分片參數開發分片任務；- 子任務：每個任務都擁有一個唯一的任務ID(任務ID可以從任務列表獲取)，當本任務執行結束並且執行成功時，將會觸發子任務ID所對應的任務的一次主動調度。- 調度過期策略：- 忽略：調度過期后，忽略過期的任務，從當前時間開始重新計算下次觸發時間；- 立即執行一次：調度過期后，立即執行一次，並從當前時間開始重新計算下次觸發時間；- 阻塞處理策略：調度過於密集執行器來不及處理時的處理策略；單機串行（默認）：調度請求進入單機執行器后，調度請求進入FIFO隊列並以串行方式運行；丟棄后續調度：調度請求進入單機執行器后，發現執行器存在運行的調度任務，本次請求將會被丟棄並標記為失敗；覆蓋之前調度：調度請求進入單機執行器后，發現執行器存在運行的調度任務，將會終止運行中的調度任務並清空隊列，然后運行本地調度任務；- 任務超時時間：支持自定義任務超時時間，任務運行超時將會主動中斷任務；- 失敗重試次數；支持自定義任務失敗重試次數，當任務失敗時將會按照預設的失敗重試次數主動進行重試；
3.1 BEAN模式（類形式）
Bean模式任務，支持基於類的開發方式，每個任務對應一個Java類。
- 優點：不限制項目環境，兼容性好。即使是無框架項目，如main方法直接啟動的項目也可以提供支持，可以參考示例項目 “xxl-job-executor-sample-frameless”；
- 缺點：
- 每個任務需要占用一個Java類，造成類的浪費；
- 不支持自動掃描任務並注入到執行器容器，需要手動注入。
執行器屬性說明
AppName: 是每個執行器集群的唯一標示AppName, 執行器會周期性以AppName為對象進行自動注冊。可通過該配置自動發現注冊成功的執行器, 供任務調度時使用;名稱: 執行器的名稱, 因為AppName限制字母數字等組成,可讀性不強, 名稱為了提高執行器的可讀性;排序: 執行器的排序, 系統中需要執行器的地方,如任務新增, 將會按照該排序讀取可用的執行器列表;注冊方式：調度中心獲取執行器地址的方式；自動注冊：執行器自動進行執行器注冊，調度中心通過底層注冊表可以動態發現執行器機器地址；手動錄入：人工手動錄入執行器的地址信息，多地址逗號分隔，供調度中心使用；機器地址："注冊方式"為"手動錄入"時有效，支持人工維護執行器的地址信息；
4.5 啟動/停止任務
可對任務進行“啟動”和“停止”操作。
需要注意的是，此處的啟動/停止僅針對任務的后續調度觸發行為，不會影響到已經觸發的調度任務，如需終止已經觸發的調度任務，可查看“4.9 終止運行中的任務”
4.6 手動觸發一次調度
點擊“執行”按鈕，可手動觸發一次任務調度，不影響原有調度規則。
4.12 用戶管理
進入 “用戶管理” 界面，可查看和管理用戶信息；
目前用戶分為兩種角色：
- 管理員：擁有全量權限，支持在線管理用戶信息，為用戶分配權限，權限分配粒度為執行器；
- 普通用戶：僅擁有被分配權限的執行器，及相關任務的操作權限；
5.3.1 設計思想
將調度行為抽象形成“調度中心”公共平台，而平台自身並不承擔業務邏輯，“調度中心”負責發起調度請求。
將任務抽象成分散的JobHandler，交由“執行器”統一管理，“執行器”負責接收調度請求並執行對應的JobHandler中業務邏輯。
因此，“調度”和“任務”兩部分可以相互解耦，提高系統整體穩定性和擴展性；
5.3.2 系統組成
- 調度模塊（調度中心）：
負責管理調度信息，按照調度配置發出調度請求，自身不承擔業務代碼。調度系統與任務解耦，提高了系統可用性和穩定性，同時調度系統性能不再受限於任務模塊；
支持可視化、簡單且動態的管理調度信息，包括任務新建，更新，刪除，GLUE開發和任務報警等，所有上述操作都會實時生效，同時支持監控調度結果以及執行日志，支持執行器Failover。 - 執行模塊（執行器）：
負責接收調度請求並執行任務邏輯。任務模塊專注於任務的執行等操作，開發和維護更加簡單和高效；
接收“調度中心”的執行請求、終止請求和日志請求等。
5.4.1 quartz的不足
Quartz作為開源作業調度中的佼佼者，是作業調度的首選。但是集群環境中Quartz采用API的方式對任務進行管理，從而可以避免上述問題，但是同樣存在以下問題：
- 問題一：調用API的的方式操作任務，不人性化；
- 問題二：需要持久化業務QuartzJobBean到底層數據表中，系統侵入性相當嚴重。
- 問題三：調度邏輯和QuartzJobBean耦合在同一個項目中，這將導致一個問題，在調度任務數量逐漸增多，同時調度任務邏輯逐漸加重的情況下，此時調度系統的性能將大大受限於業務；
- 問題四：quartz底層以“搶占式”獲取DB鎖並由搶占成功節點負責運行任務，會導致節點負載懸殊非常大；而XXL-JOB通過執行器實現“協同分配式”運行任務，充分發揮集群優勢，負載各節點均衡。
XXL-JOB彌補了quartz的上述不足之處。
5.4.8 任務HA（Failover）
執行器如若集群部署，調度中心將會感知到在線的所有執行器，如“127.0.0.1:9997, 127.0.0.1:9998, 127.0.0.1:9999”。
當任務”路由策略”選擇”故障轉移(FAILOVER)”時，當調度中心每次發起調度請求時，會按照順序對執行器發出心跳檢測請求，第一個檢測為存活狀態的執行器將會被選定並發送調度請求。
5.4.9 調度日志
調度中心每次進行任務調度，都會記錄一條任務日志，任務日志主要包括以下三部分內容：
- 任務信息：包括“執行器地址”、“JobHandler”和“執行參數”等屬性，點擊任務ID按鈕可查看，根據這些參數，可以精確的定位任務執行的具體機器和任務代碼；
- 調度信息：包括“調度時間”、“調度結果”和“調度日志”等，根據這些參數，可以了解“調度中心”發起調度請求時具體情況。
- 執行信息：包括“執行時間”、“執行結果”和“執行日志”等，根據這些參數，可以了解在“執行器”端任務執行的具體情況；
調度日志，針對單次調度，屬性說明如下：
- 執行器地址：任務執行的機器地址；
- JobHandler：Bean模式表示任務執行的JobHandler名稱；
- 任務參數：任務執行的入參；
- 調度時間：調度中心，發起調度的時間；
- 調度結果：調度中心，發起調度的結果，SUCCESS或FAIL；
- 調度備注：調度中心，發起調度的備注信息，如地址心跳檢測日志等；
- 執行時間：執行器，任務執行結束后回調的時間；
- 執行結果：執行器，任務執行的結果，SUCCESS或FAIL；
- 執行備注：執行器，任務執行的備注信息，如異常日志等；
- 執行日志：任務執行過程中，業務代碼中打印的完整執行日志，見“4.8 查看執行日志”；
5.5.1 “Bean模式” 任務
開發步驟：可參考 “章節三” ；
原理：每個Bean模式任務都是一個Spring的Bean類實例，它被維護在“執行器”項目的Spring容器中。任務類需要加“@JobHandler(value=”名稱”)”注解，因為“執行器”會根據該注解識別Spring容器中的任務。任務類需要繼承統一接口“IJobHandler”，任務邏輯在execute方法中開發，因為“執行器”在接收到調度中心的調度請求時，將會調用“IJobHandler”的execute方法，執行任務邏輯。
5.5.4 執行器
執行器實際上是一個內嵌的Server，默認端口9999（配置項：xxl.job.executor.port）。
在項目啟動時，執行器會通過“@JobHandler”識別Spring容器中“Bean模式任務”，以注解的value屬性為key管理起來。
“執行器”接收到“調度中心”的調度請求時，如果任務類型為“Bean模式”，將會匹配Spring容器中的“Bean模式任務”，然后調用其execute方法，執行任務邏輯。如果任務類型為“GLUE模式”，將會加載GLue代碼，實例化Java對象，注入依賴的Spring服務（注意：Glue代碼中注入的Spring服務，必須存在與該“執行器”項目的Spring容器中），然后調用execute方法，執行任務邏輯。
5.5.5 任務日志
XXL-JOB會為每次調度請求生成一個單獨的日志文件，需要通過 “XxlJobHelper.log” 打印執行日志，“調度中心”查看執行日志時將會加載對應的日志文件。
(歷史版本通過重寫LOG4J的Appender實現，存在依賴限制，該方式在新版本已經被拋棄)
日志文件存放的位置可在“執行器”配置文件進行自定義，默認目錄格式為：/data/applogs/xxl-job/jobhandler/“格式化日期”/“數據庫調度日志記錄的主鍵ID.log”。
在JobHandler中開啟子線程時，子線程將會將會把日志打印在父線程即JobHandler的執行日志中，方便日志追蹤。
5.11 故障轉移 & 失敗重試
一次完整任務流程包括”調度（調度中心） + 執行（執行器）”兩個階段。
- “故障轉移”發生在調度階段，在執行器集群部署時，如果某一台執行器發生故障，該策略支持自動進行Failover切換到一台正常的執行器機器並且完成調度請求流程。
- “失敗重試”發生在”調度 + 執行”兩個階段，支持通過自定義任務失敗重試次數，當任務失敗時將會按照預設的失敗重試次數主動進行重試；
5.14 任務超時控制
支持設置任務超時時間，任務運行超時的情況下，將會主動中斷任務；
需要注意的是，任務超時中斷時與任務終止機制（可查看“4.9 終止運行中的任務”）類似，也是通過 “interrupt” 中斷任務，因此業務代碼需要將 “InterruptedException” 外拋，否則功能不可用。
5.16 任務失敗告警
默認提供郵件失敗告警，可擴展短信、釘釘等方式。如果需要新增一種告警方式，只需要新增一個實現 “com.xxl.job.admin.core.alarm.JobAlarm” 接口的告警實現即可。可以參考默認提供郵箱告警實現 “EmailJobAlarm”。
5.20 避免任務重復執行
調度密集或者耗時任務可能會導致任務阻塞，集群情況下調度組件小概率情況下會重復觸發；
針對上述情況，可以通過結合 “單機路由策略（如：第一台、一致性哈希）” + “阻塞策略（如：單機串行、丟棄后續調度）” 來規避，最終避免任務重復執行。
https://www.xuxueli.com/xxl-job/#1.1%20%E6%A6%82%E8%BF%B0