考拉定時任務框架kSchedule

此文已由做者楊凱明受權網易雲社區發佈。

歡迎訪問網易雲社區，瞭解更多網易技術產品運營經驗。

1.背景

目前項目中使用的定時任務框架存在下面這些問題

• 沒有統一的定時任務管理平臺

目前項目中使用定時任務的方式比較混亂，有部分系統使用了cron插件，有部分系統直接使用的spring task註解配置，沒有一個統一的管理平臺。使用cron插件的定時任務的配置集成在ms後臺，管理頁面比較簡陋，須要一個更加友好、功能更加完善的管理系統，專門負責定時任務的管理，包括定時任務的建立、修改、刪除、觸發、查看歷史等

• 對每一個定時任務沒有完善的監控

目前項目中沒有對定時任務的監控，沒法知道定時任務的執行狀況和執行時間;當定時任務沒有觸發時沒有告警;無法查看定時任務的執行歷史狀況

• 單點問題

目前使用spring task或quartz來作定時任務的系統，都須要手動指定運行定時任務的機器，這樣會致使某臺機器負載很高，而且若是這臺機器宕機了則定時任務都不會執行

• 重複執行問題
  

有些定時任務自己不是冪等的，若是重複執行的話會有不少問題，好比短信的定時發送等；目前cron出現過zk斷開後，致使定時任務被重複執行的狀況

針對這些問題，須要設計一種能解決上述問題的新框架

2.設計

設計目標：

1. 定時任務統一配置、統一管理

2. 支持動態修改任務狀態，動態暫停/恢復任務，即時生效

3.  減小使用方的限制依賴

4.  定時任務不遺漏、不重複的被執行

5. 支持任務分片併發執行

6. 完善的監控、統計功能

整個框架分爲四部分：

1. 調度服務器管理平臺：負責定時任務的配置和管理，並定時進行任務的分配；獲取每次任務執行的結果進行統計

2. 任務執行器：經過心跳更新服務器信息；獲取配置的任務信息定時執行任務，並根據任務執行狀況上報執行結果

3.  zk集羣：存儲任務配置信息和服務器節點信息；提供分佈式協調服務

4. 數據庫：記錄任務的每次執行狀況，用於監控和統計
   

 

架構部署圖以下：

ZK節點圖：

觸發類型:

• 定時觸發:經過定時任務框架與cron表達式定時觸發

• 手動觸發:經過kschedule平臺觸發(1.按分配信息觸發;2.指定一臺機器執行)

• 啓動觸發:應用啓動時觸發(如加載初始化本地緩存)

• RPC觸發:經過dubbo接口觸發

任務類型:

• 都不執行(只需人爲去觸發，使用場景較少)

• 全部的機器上只有一臺執行:該產品下全部註冊上來的機器只會選擇一臺來執行

• 全部機器都執行:該產品下全部註冊上來的機器都會執行該任務

• 在指定的機器上所有執行:被選擇的機器都會執行該任務

• 指定的機器上只有一臺執行:被選擇的機器中只會有一臺會執行該任務

• 任務分片執行(下面解釋)

不重複執行策略及異常整理

• 任務狀態變爲DOING狀態後，備用機器再也不監放任務，認爲任務已經有機器執行，如執行的機器在任務執行時掛掉，則形成任務遺漏執行。

• 如主機器500ms內沒有將任務變爲DOING狀態，則備用機器恢復搶鎖進行任務執行，沒搶到鎖的機器繼續監放任務狀態。
  

1. kschedule服務端掛了：不影響任務執行

2. 執行前服務器網絡斷開：由備機執行

3. 執行前服務器掛掉：由備機執行

4. 執行中服務器網絡斷開:任務正常執行，可能會報警遺漏執行

5. 執行中服務器掛掉：任務不能正常執行，會報警

6. zk掛掉：任務不能正常（zk進程監控）

7. 執行分配的機器全掛掉:任務不能正常執行，會報警

不遺漏執行策略及異常整理

• 任務狀態變爲DOING狀態後，備用機器繼續監放任務，直到任務狀態變動爲DONE時，監聽取消。

• 如主機器在DOING狀態後掛掉或者失去與ZK的鏈接，則備用機器恢復搶鎖進行任務執行，沒搶到鎖的機器繼續監放任務狀態，可能會形成任務重複執行。

1. kschedule服務端掛了：不影響任務執行

2. 執行前服務器網絡斷開：由備機執行

3. 執行前服務器掛掉：由備機執行

4. 執行中服務器網絡斷開：由備機執行，可能重複執行

5. 執行中服務器掛掉：由備機執行

6. 執行中任務執行超時：由備機執行，可能重複執行

7. zk掛掉：任務不能正常（ zk進程監控）

8. 執行分配的機器全掛掉:任務不能正常執行，會報警

分片任務：

分片任務即將一個任務按必定規則拆成多個子任務在多臺機器上的多個線程中並行執行。

須要實現IScheduleShardingTask接口，

例子1：服務器有5臺

分片信息:0，1，2，3，4，5，6，7，8，9

分片最大線程數:10

分片獲取數據的數量:100

則kschedule會將任務進行分片，每臺機器分配到2個執行線程，每一個線程執行1個分片，每一個分片拉取100條數據。

每一個線程回調到selectItems方法上的參數爲selectItems(null,10,[0],100);

selectItems：應用系統在接口實現中根據分片傳入的參數去DB拉取待處理的數據。

execute：應用系統在接口實現中根據selectItems方法拉取的數據進行數據處理。

例子2: 服務器有5臺

分片信息:a,b,c,d,e,f,g,h,i,j,k,l,m,n,o,p,q,r,s,t,u,v,w,x,y,z

分片最大線程數:10

分片獲取數據的數量:1000

則kschedule會將任務進行分片，每臺機器分配到2個執行線程，每一個線程執行3個分片(部分是2個分片)，每一個分片拉取1000條數據。

每一個線程回調到selectItems方法上的參數爲selectItems(null,26,[a,b,c],1000);

selectItems：應用系統在接口實現中根據分片傳入的參數去DB拉取待處理的數據。

execute：應用系統在接口實現中根據selectItems方法拉取的數據進行數據處理。

/**
 * 分片任務定義接口，業務方需實現該接口才能使用分片功能
 * @author hzyangkaiming
 *
 */public interface IScheduleShardingTask {    /**
     * 拉取業務數據的方法
     * @param parameter 自定義參數
     * @param shardingCount 任務分片總數
     * @param shardingIndexs 分配到的任務分片
     * @param limit 每次獲取數據的數量
     * @return 待處理的數據
     * @author yangkaiming
     * @since 2016年5月16日
     */
    public List selectItems(String parameter,int shardingCount,List shardingIndexs,int limit);    /**
     * 執行指定的任務
     *
     * @param items 處理的數據
     * @return 成功/失敗
     * @author yangkaiming
     * @since 2016年5月16日
     */
    public boolean execute(T[] items);

執行日誌:

執行日誌會在框架調度業務方法時進行記錄，寫到ZK，kschedule平臺會收集並清理zk。

用戶能夠在kschedule平臺查詢任務執行狀況，包括執行時間狀況，任務每次觸發執行的服務器等信息

3.監控

1.根據cron表達式及任務執行日誌，對任務漏執行、重複執行、超時執行等進行準實時報警。

2.任務執行失敗(業務方法未捕獲的Exeption)報警，並推送錯誤堆棧，幫助定位解決問題。

2.支持很是規節假日短信報警，平日上班時間popo、stone報警，下班時間popo、stone、短信報警。

4.實踐

通過一年的推廣及優化，考拉目前各系統定時任務已經基本完成切換，並穩定運行於kschedule平臺，固然也有很多坑：

坑1：業務方法卡住

背景：定時任務運行時會佔有該任務的分佈式鎖，若是任務掛住會形成後面每次觸發任務都會忽略執行，防止重複執行。

問題: http,ftp等外部調用相關業務定時任務出現任務掛住的問題

實時處理:任務出現超時並長期運行中，則優先打印堆棧信息，保留現場，並根據業務方評估是否人工去zk釋放鎖，讓任務先跑起來。

後期處理:業務放根據堆棧等信息定位卡主緣由進行優化(主要以超時時間爲主)，平臺增長實時zk鎖查詢，判斷任務是否佔用鎖，並增長管理員刪鎖按鈕，提高運維能力。

坑2:新上線分片任務重複執行並執行紊亂

背景:分片任務會根據分配信息異步起線程(有默認線程池)進行處理，而且單個分片沒有加分片的分佈式鎖。業務放上線10個分片任務，每一個分片任務10個線程，總共4臺機器，觸發時間都是每分鐘的0秒，默認線程池5個初始線程，1000的隊列，隊列滿擴到20個線程

問題:業務系統上線，業務系統ftp調用超時問題也比較多，形成分片任務執行徹底紊亂，執行日誌無參考性，業務方法出現重複執行

實時處理:通過初步判斷,根據業務方分片任務數量及線程量，優先加大線程池提升處理能力，緊急上線，但不能徹底解決問題。

後期處理:修改默認線程池策略，去掉緩衝隊列，線程不夠直接擴，最大200個，超過150個報警；由於業務方須要高頻率調度這些分片任務，加上與ftp調用等執行時間不可控因素，所以增長單個分片的分佈式鎖，防止重複執行，而且極大下降線程佔用量。

那麼如今：

kschedule平臺目前每日的任務執行次數平均在20+w次。

網易金融也已搭建本身的kschedule環境，並在線上使用中。

考拉訂單流推送、申報單推送、物流信息等供應鏈相關業務已接入分片任務，極大提升了業務吞吐量、下降DB壓力，提高了通關效率。

支撐雙11、黑5、雙十二等大促，高峯期統一暫停非關鍵定時任務，讓出系統資源，提升業務系統穩定性。

5.計劃

近：任務執行時間TOP統計，方便業務系統優化定時任務性能等；

遠：能夠根據考拉的業務須要，增長非java方法調度功能等；

歡迎考拉的兄弟姐妹貢獻需求及改進點

網易雲免費體驗館，0成本體驗20+款雲產品！ 

更多網易技術、產品、運營經驗分享請點擊。

相關文章：
【推薦】 Android TV 開發 （1）