下面這個例子很好的覆蓋了Quartz最重要的3個基本要素：
例子中是HelloQuartz。 為什麽設計成JobDetail + Job，不直接使用Job？這是因為任務是有可能並發執行，如果Scheduler直接使用Job，就會存在對同壹個Job實例並發訪問的問題。而JobDetail & Job 方式，sheduler每次執行，都會根據JobDetail創建壹個新的Job實例，這樣就可以規避並發訪問的問題。
定義Job類為HelloQuartz類，這是真正的執行邏輯所在
當當是在quartz的基礎上封裝了quartz，對應的有
1.創建壹個org.quartz.Job的實現類，並實現實現自己的業務邏輯。
public final class LiteJob implements Job {}
2.定義壹個JobDetail，引用這個實現類 。
3.Scheduler調度器。
以下舉例說明如何使用當當：
設置分片參數，定義Job配置類，執行計劃等配置
定義Job類
意為簡單實現，未經任何封裝的類型。需實現SimpleJob接口。該接口僅提供單壹方法用於覆蓋，此方法將定時執行。與Quartz原生接口相似，但提供了彈性擴縮容和分片等功能。
Dataflow類型用於處理數據流，需實現DataflowJob接口。該接口提供2個方法可供覆蓋，分別用於抓取(fetchData)和處理(processData)數據。
流式作業：涉及到兩個概念分片分批
即上面重寫的兩個方法中
fetchData 用於抓取，如數據庫中的待抓取歌曲中有壹個字段用來標識該任務是屬於哪壹個分片，即到時候會在哪壹個分片上執行。如有兩個分片，用分片號0、1表示。1000首待抓取的歌，500首標記為0，500首標記為1。那麽到時候我們將歌曲的信息作為上下文參數傳入到fetch方法中，500首歌可以limit 100，每次查出100首歌進行處理，這就叫分批，壹個任務被分成了2片，每片裏面按照100首歌壹批，分5批執行完。
processData 就是按照批次每次處理100首歌，其中100首歌作為壹個子事物，其中有壹首歌拋異常或者出現任何失敗，那麽都認為這個批次執行失敗，下次會將這個批次內的所有任務數據在執行壹遍。
事件追蹤的event_trace_rdb_url屬性對應庫自動創建JOB_EXECUTION_LOG和JOB_STATUS_TRACE_LOG兩張表以及若幹索引。
JOB_EXECUTION_LOG記錄每次作業的執行 歷史 。分為兩個步驟：
作業開始執行時向數據庫插入數據，除failure_cause和complete_time外的其他字段均不為空。
作業完成執行時向數據庫更新數據，更新is_success, complete_time和failure_cause(如果作業執行失敗)。
JOB_STATUS_TRACE_LOG記錄作業狀態變更痕跡表。可通過每次作業運行的task_id查詢作業狀態變化的生命周期和運行軌跡。
可通過配置多個任務監聽器，在任務執行前和執行後執行監聽的方法。監聽器分為每臺作業節點均執行和分布式場景中僅單壹節點執行2種。
若作業處理作業服務器的文件，處理完成後刪除文件，可考慮使用每個節點均執行清理任務。此類型任務實現簡單，且無需考慮全局分布式任務是否完成，請盡量使用此類型監聽器。
步驟：
定義監聽
將監聽器作為參數傳入JobScheduler
若作業處理數據庫數據，處理完成後只需壹個節點完成數據清理任務即可。此類型任務處理復雜，需同步分布式環境下作業的狀態同步，提供了超時設置來避免作業不同步導致的死鎖，請謹慎使用。
步驟：
定義監聽
將監聽器作為參數傳入JobScheduler
全路徑：
io.elasticjob.lite.api.strategy.impl.AverageAllocationJobShardingStrategy
策略說明：
基於平均分配算法的分片策略，也是默認的分片策略。
如果分片不能整除，則不能整除的多余分片將依次追加到序號小的服務器。如：
如果有3臺服務器，分成9片，則每臺服務器分到的分片是：1=[0,1,2], 2=[3,4,5], 3=[6,7,8]
如果有3臺服務器，分成8片，則每臺服務器分到的分片是：1=[0,1,6], 2=[2,3,7], 3=[4,5]
如果有3臺服務器，分成10片，則每臺服務器分到的分片是：1=[0,1,2,9], 2=[3,4,5], 3=[6,7,8]
全路徑：
io.elasticjob.lite.api.strategy.impl.OdevitySortByNameJobShardingStrategy
策略說明：
根據作業名的哈希值奇偶數決定IP升降序算法的分片策略。
作業名的哈希值為奇數則IP升序。
作業名的哈希值為偶數則IP降序。
用於不同的作業平均分配負載至不同的服務器。
全路徑：
io.elasticjob.lite.api.strategy.impl.RotateServerByNameJobShardingStrategy
策略說明：
根據作業名的哈希值對服務器列表進行輪轉的分片策略。
解壓縮elastic-job-lite-console-${version}.tar.gz並執行binstart.sh。打開瀏覽器訪問http://localhost:8899/即可訪問控制臺。8899為默認端口號，可通過啟動腳本輸入-p自定義端口號。
elastic-job-lite-console-${version}.tar.gz可通過mvn install編譯獲取。
登錄
提供兩種賬戶，管理員及訪客，管理員擁有全部操作權限，訪客僅擁有察看權限。默認管理員用戶名和密碼是root/root，訪客用戶名和密碼是guest/guest，可通過confauth.properties修改管理員及訪客用戶名及密碼。
功能列表
登錄安全控制
註冊中心、事件追蹤數據源管理
快捷修改作業設置
作業和服務器維度狀態查看
操作作業禁用啟用、停止和刪除等生命周期
事件追蹤查詢
備註：
請使用JDK1.7及其以上版本
請使用Zookeeper 3.4.6及其以上版本
請使用Maven 3.0.4及其以上版本
註冊中心在定義的命名空間下，創建作業名稱節點，用於區分不同作業，所以作業壹旦創建則不能修改作業名稱，如果修改名稱將視為新的作業。作業名稱節點下又包含4個數據子節點，分別是config, instances, sharding, servers和leader。
config節點
作業配置信息，以JSON格式存儲
instances節點
作業運行實例信息，子節點是當前作業運行實例的主鍵。作業運行實例主鍵由作業運行服務器的IP地址和PID構成。作業運行實例主鍵均為臨時節點，當作業實例上線時註冊，下線時自動清理。註冊中心監控這些節點的變化來協調分布式作業的分片以及高可用。 可在作業運行實例節點寫入TRIGGER表示該實例立即執行壹次。
sharding節點
作業分片信息，子節點是分片項序號，從零開始，至分片總數減壹。分片項序號的子節點存儲詳細信息。每個分片項下的子節點用於控制和記錄分片運行狀態。節點詳細信息說明：
servers節點
作業服務器信息，子節點是作業服務器的IP地址。可在IP地址節點寫入DISABLED表示該服務器禁用。 在新的cloud native架構下，servers節點大幅弱化，僅包含控制服務器是否可以禁用這壹功能。為了更加純粹的實現job核心，servers功能未來可能刪除，控制服務器是否禁用的能力應該下放至自動化部署系統。
leader節點
作業服務器主節點信息，分為election，sharding和failover三個子節點。分別用於主節點選舉，分片和失效轉移處理。
leader節點是內部使用的節點，如果對作業框架原理不感興趣，可不關註此節點。
我是 「翎野君」 ，感謝各位朋友的： 點贊 、 收藏 和 評論 ，我們下期見。