xxl-job是一個分布式定時任務調度框架，功能強大，底層使用自己實作的rpc框架進行注冊和管理，資料庫使用mysql，調度觸發使用資料庫鎖來作為調度鎖，
xxl-job主要分為調度中心admin以及任務，任務引入依賴jar包并配置啟動類為spring所管理的bean后，將自動通過spring-bean提供的initMethod進行啟動執行緒選擇一個埠進行注冊以及監聽任務調度，
公司目前引入xxl-job框架代替quartz框架作為分布式任務調度組件，并在其之上進行一定開發以及優化，所以這篇文章主要分享一些深入使用，主要是概念的詳細介紹，
由于篇幅有限，這里沒有寫的很詳細，有需要完整版和更多知識點介紹的朋友可以點一點下方鏈接免費領取
鏈接：1103806531暗號：CSDN
系統關鍵概念介紹
執行器
配置中心配置的執行器，概念上對應執行定時任務的服務，支持分布式調度以及調度的各種路由規則配置，注冊方式支持自動注冊和手動配置機器地址兩種方式，心跳時間間隔默認為30s，失效時間90s，
執行器自動注冊后，調度中心頁面依舊有最長30秒的延遲顯示，原因是資料庫中注冊表更新后，展示執行器的表是由另一個守護執行緒去更新的，更新頻率為默認心跳時間30s，所以管理臺展示會有延遲，但不影響任務調度，
任務
任務以執行器為維度配置，每個任務必須屬于一個執行器，當任務觸發時會根據該任務所屬的執行器去尋找執行器的地址串列，然后通過配置的路由規則以及阻塞規則去去執行，
任務支持本地任務以及遠程任務，本地任務即按照執行方寫好的業務邏輯執行，遠程任務通過GLUE，在調度中心管理臺寫好代碼，分發到執行方去執行，建議無特殊需求的話，統一使用本地任務，
任務配置項描述
- 執行器：選擇該任務由哪個執行器去執行
- 任務描述：簡單描述該任務的功能以及作用，如：訂單定時跑批
- 路由策略：設定任務執行時，如何去選擇執行器，高頻任務建議使用一致性哈希或者第一臺執行
- Cron：Cron運算式，描述任務運行的時間
- 運行模式：BEAN即為接入服務配置在本地對應的handler運行，其他方式均為管理臺設定代碼交由接入服務遠程執行
- JobHandler：運行模式為BEAN時必填，值應當為接入服務本地執行任務的handler
- 阻塞策略：當同一任務多次調度到同一臺執行器時，執行器應當使用的策略
- 子任務ID：如配置，則該任務完成后自動觸發一次子任務的執行
- 任務超時時間：配置后當任務超時時將自動終止任務執行，
- 失敗重試次數：任務失敗后重試的次數，
- 負責人：一般為該任務接入方的負責人
- 報警郵件：任務報警后發送的郵件地址
- 任務引數：若配置了任務引數，任務調度時將發送任務引數至執行方handler，
阻塞策略
阻塞策略即同一個任務在執行器的阻塞執行策略，由執行器端控制，典型場景為：任務A分發到執行器A執行，此時任務A再次觸發并分發到執行器A，此時根據阻塞策略選擇的不同將會有以下三種執行策略：
- 單機串行 該策略下，同一執行器收到同一任務的調度觸發時，若已有任務正在執行，會將后續的任務放入執行執行緒的佇列中，等待執行緒輪詢繼續執行，可能會導致執行緒佇列阻塞過多任務導致記憶體過高，高頻且耗時較長任務慎用，
- 丟棄后續調度 該策略下，同一執行器收到同一任務的調度觸發時，若已有任務正在執行，會直接丟棄后續同一任務的調度，推薦使用，
- 覆寫之前調度 該策略下，同一執行器收到同一任務的調度觸發時，若已有任務正在執行，將會直接停止正在執行的任務（通過執行緒InterruptedException例外以及volatile變數判斷），并將新任務放入佇列，一般情況下不建議使用，
路由策略
路由策略即任務在配置中心進行調度分發時，選擇執行器的策略，由配置中心端控制，典型場景為：任務A觸發執行，任務A對應的執行器有執行器A，B，C，D，此時根據路由策略的選擇將會有以下幾種分發情況
- 第一個：始終選擇第一臺執行器作為任務執行器，不論該任務執行器是否正常，
- 最后一個：始終選擇最后一臺作為任務執行器
- 輪詢：每個執行器輪流執行
- 隨機：隨機選擇一個執行器執行
- 一致性HASH：根據任務ID做一致性哈希選擇執行器，同一個任務必定只分發到同一個執行器，高頻或耗時較長任務推薦使用
- 最不經常使用：選擇平均使用頻率最低的執行器，
- 最近最久未使用：選擇最近的最久未使用的執行器，
- 故障轉移：分別進行心跳檢測，選擇第一臺心跳檢測正常的機器執行，
- 忙碌轉移：分別進行忙碌檢測，選擇第一臺空閑的機器執行，
- 分片廣播：廣播到所有執行器執行，并提供分片引數，分片引數獲取方式如下，應用在被觸發時動態獲取自己是第幾個分片，共有幾個分片：
日志問題
xxl-job相關日志使用默認使用slf4j作為日志框架，使用專門的API寫入日志時，會輸出2種日志，客戶端日志與服務端日志
客戶端日志
客戶端日志根據組態檔中配置的logpath指定，根據原始碼分析，客戶端日志將通過FileOutputStream寫到對應檔案，且無法通過配置修改，所以只好修改了原始碼中的邏輯，改為該值為空未配置時，直接通過slf4j寫入，
服務端日志
使用xxljob的日志api輸出日志時，日志也會在調度管理臺看到，能看到的原理是xxl-job管理臺會通過rpc呼叫執行器的介面，執行器收到請求后從指定的日志檔案中讀取執行的日志并回傳，這里存在一個比較麻煩的問題，就是xxl-job這種日志的邏輯，無法很好的兼容到專案統一的日志模塊里，十分不便，
所以實際使用程序中，我們在xxl-job管理臺查詢日志時，對其進行了改造，修改為不從rpc查詢，而是走我們日志管理的搜索引擎根據執行的jobid查詢相關日志，結合客戶端日志輸出的改造，從而統一xxl-job和我們系統間的日志管理，
框架目前發現的缺點以及存在的問題
- 目前定時任務的調度串行是依賴db鎖的，某個子微服務或者子系統內部使用還好，但是不適合整個公司級別共用，這點和資料庫的耦合比較高，并沒有本地快取之類的，對資料庫的HA依賴非常高，
- 管理模塊以及權限模塊，組內和小公司用用可以，不適合作為多個系統多個部門之間共用的中間件，
- 管理臺存在一些簡單的安全bug，sql注入和js腳本注入非常簡單，（公司的安全測驗測出來的）
- 相關協議支持較差，使用自己實作的RPC協議,如果需要dubbo或者spring cloud，需要自己拓展，并且雖然底層是netty，但是本身對netty例外的封裝并不是很好，導致一些奇怪的網路問題或者其他的協議，會報莫名其妙的錯，沒有一定netty理解的人是看不懂的，這點我提了Issue，不過出于這套框架解耦與獨立的設計，估計是不會支持dubbo和spring cloud的，
- 上面提到的，日志模塊更建議自己整體修改下寫入邏輯，管理臺看不到無所謂，（畢竟定時任務也沒誰會去管理臺看日志，并且這部分日志寫多了對性能和網路開銷有影響的），寫到本地使用elk之類的再查就可以了，
- 定時任務觸發的流水號或者跟蹤id，需要改動原框架，否則也會影響后續日志追蹤的問題，
總體而言這是一個很不錯的框架，關于定時任務的執行器和調度器關系也很優雅,值得拓展或者進行一定定制開發，目前使用來，穩定性也沒有問題，
最后
為大家整理了各個知識點模塊整理檔案（微服務、資料庫、mysql、jvm、Redis等都有）和更多大廠面試真題，有需要的朋友可以點一點下方鏈接免費領取
鏈接：1103806531暗號：CSDN
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/197802.html
標籤：其他