資訊專欄INFORMATION COLUMN
摘要：考拉訂單流推送申報單推送物流信息等供應鏈相關業務已接入分片任務，極大提高了業務吞吐量降低壓力，提升了通關效率。支撐雙十一黑五雙十二等大促，高峰期統一暫停非關鍵定時任務，讓出系統資源，提高業務系統穩定性。
此文已由作者楊凱明授權網易云社區發布。
歡迎訪問網易云社區，了解更多網易技術產品運營經驗。
1.背景
目前項目中使用的定時任務框架存在下面這些問題
沒有統一的定時任務管理平臺
目前項目中使用定時任務的方式比較混亂，有部分系統使用了cron插件，有部分系統直接使用的spring task注解配置，沒有一個統一的管理平臺。使用cron插件的定時任務的配置集成在ms后臺，管理頁面比較簡陋，需要一個更加友好、功能更加完善的管理系統，專門負責定時任務的管理，包括定時任務的創建、修改、刪除、觸發、查看歷史等
對每個定時任務沒有完善的監控
目前項目中沒有對定時任務的監控，無法知道定時任務的執行情況和執行時間;當定時任務沒有觸發時沒有告警;沒法查看定時任務的執行歷史情況
單點問題
目前使用spring task或quartz來做定時任務的系統，都需要手動指定運行定時任務的機器，這樣會導致某臺機器負載很高，并且如果這臺機器宕機了則定時任務都不會執行
重復執行問題
有些定時任務本身不是冪等的，如果重復執行的話會有很多問題，比如短信的定時發送等；目前cron出現過zk斷開后，導致定時任務被重復執行的情況
針對這些問題，需要設計一種能解決上述問題的新框架
2.設計
設計目標：
定時任務統一配置、統一管理
支持動態修改任務狀態，動態暫停/恢復任務，即時生效
減少使用方的限制依賴
定時任務不遺漏、不重復的被執行
支持任務分片并發執行
完善的監控、統計功能
整個框架分為四部分：
調度服務器管理平臺：負責定時任務的配置和管理，并定時進行任務的分配；獲取每次任務執行的結果進行統計
任務執行器：通過心跳更新服務器信息；獲取配置的任務信息定時執行任務，并根據任務執行情況上報執行結果
zk集群：存儲任務配置信息和服務器節點信息；提供分布式協調服務
數據庫：記錄任務的每次執行情況，用于監控和統計
架構部署圖如下：
ZK節點圖：
觸發類型:
定時觸發:通過定時任務框架與cron表達式定時觸發
手動觸發:通過kschedule平臺觸發(1.按分配信息觸發;2.指定一臺機器執行)
啟動觸發:應用啟動時觸發(如加載初始化本地緩存)
RPC觸發:通過dubbo接口觸發
任務類型:
都不執行(只需人為去觸發，使用場景較少)
所有的機器上只有一臺執行:該產品下所有注冊上來的機器只會選擇一臺來執行
所有機器都執行:該產品下所有注冊上來的機器都會執行該任務
在指定的機器上全部執行:被選擇的機器都會執行該任務
指定的機器上只有一臺執行:被選擇的機器中只會有一臺會執行該任務
任務分片執行(下面解釋)
不重復執行策略及異常整理
任務狀態變為DOING狀態后，備用機器不再監聽任務，認為任務已經有機器執行，如執行的機器在任務執行時掛掉，則造成任務遺漏執行。
如主機器500ms內沒有將任務變為DOING狀態，則備用機器恢復搶鎖進行任務執行，沒搶到鎖的機器繼續監聽任務狀態。
kschedule服務端掛了：不影響任務執行
執行前服務器網絡斷開：由備機執行
執行前服務器掛掉：由備機執行
執行中服務器網絡斷開:任務正常執行，可能會報警遺漏執行
執行中服務器掛掉：任務不能正常執行，會報警
zk掛掉：任務不能正常（zk進程監控）
執行分配的機器全掛掉:任務不能正常執行，會報警
不遺漏執行策略及異常整理
任務狀態變為DOING狀態后，備用機器繼續監聽任務，直到任務狀態變更為DONE時，監聽取消。
如主機器在DOING狀態后掛掉或者失去與ZK的連接，則備用機器恢復搶鎖進行任務執行，沒搶到鎖的機器繼續監聽任務狀態，可能會造成任務重復執行。
kschedule服務端掛了：不影響任務執行
執行前服務器網絡斷開：由備機執行
執行前服務器掛掉：由備機執行
執行中服務器網絡斷開：由備機執行，可能重復執行
執行中服務器掛掉：由備機執行
執行中任務執行超時：由備機執行，可能重復執行
zk掛掉：任務不能正常（ zk進程監控）
執行分配的機器全掛掉:任務不能正常執行，會報警
分片任務：
分片任務即將一個任務按一定規則拆成多個子任務在多臺機器上的多個線程中并行執行。
需要實現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壓力，提升了通關效率。
支撐雙十一、黑五、雙十二等大促，高峰期統一暫停非關鍵定時任務，讓出系統資源，提高業務系統穩定性。
5.計劃
近：任務執行時間TOP統計，方便業務系統優化定時任務性能等；
遠：可以根據考拉的業務需要，增加非java方法調度功能等；
歡迎考拉的兄弟姐妹貢獻需求及改進點
網易云免費體驗館，0成本體驗20+款云產品！
更多網易技術、產品、運營經驗分享請點擊。
文章來源： 網易云社區
文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。
轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/25273.html
摘要：此文已由作者王慎為授權網易云社區發布。歡迎訪問網易云社區，了解更多網易技術產品運營經驗。網易云免費體驗館，成本體驗款云產品更多網易技術產品運營經驗分享請點擊。文章來源網易云社區 此文已由作者王慎為授權網易云社區發布。 歡迎訪問網易云社區，了解更多網易技術產品運營經驗。 disconf-spring-boot-starter使用方法：引入maven依賴： com.netease.hai...
摘要：德邦快遞創始于年，從專于傳統零擔業務到現在全面發力大件快遞，業務量正處于高速增長中。網易云輕舟微服務是圍繞應用和微服務打造的一站式平臺，幫助用戶快速實現易接入易運維的微服務解決方案。 歡迎訪問網易云社區，了解更多網易技術產品運營經驗。 2018年7月31日，由杭州市政府、賽迪以及網易主辦的2018中國杭州云創大會于杭州國際博覽中心如期舉辦，大會以開放·生態·賦能為主題，匯聚行業領袖、技...
摘要：本文總結了前端老司機經常問題的一些問題并結合個人總結給出了比較詳盡的答案。網易阿里騰訊校招社招必備知識點。此外還有網絡線程，定時器任務線程，文件系統處理線程等等。線程核心是引擎。主線程和工作線程之間的通知機制叫做事件循環。 showImg(https://segmentfault.com/img/bVbu4aB?w=300&h=208); 本文總結了前端老司機經常問題的一些問題并結合個...
摘要：本文總結了前端老司機經常問題的一些問題并結合個人總結給出了比較詳盡的答案。網易阿里騰訊校招社招必備知識點。此外還有網絡線程，定時器任務線程，文件系統處理線程等等。線程核心是引擎。主線程和工作線程之間的通知機制叫做事件循環。 showImg(https://segmentfault.com/img/bVbu4aB?w=300&h=208); 本文總結了前端老司機經常問題的一些問題并結合個...
摘要：面過的公司，大疆，阿里，網易，百度，電信研發中心，深信服，華為，小米，搜狗，騰訊。拿了的公司目前是大疆電信深信服華為。一面二面因為時間太久，就直接放在一起了，問的都是基礎吧，講真，大疆前端面試不難，都是很基礎的，就是時間長，等的捉急。 自我介紹下：某985碩士，程序媛，接觸前端一年時間。從八月份開始校招面試筆試，前前后后大廠小廠也都面了挺多，不過大廠基本都被我掛完了，哭暈我，還是太菜啊...
閱讀 1818·2021-11-18 13:21
閱讀 1953·2021-10-18 13:30
閱讀 1539·2021-10-12 10:13
閱讀 906·2021-10-09 09:43
閱讀 5413·2021-09-22 15:13
閱讀 3583·2021-08-11 10:22
閱讀 936·2019-08-30 13:46
閱讀 3520·2019-08-30 13:21
