您好,登錄后才能下訂單哦!
這篇文章主要介紹“python apscheduler cron定時(shí)任務(wù)觸發(fā)接口自動(dòng)化巡檢如何實(shí)現(xiàn)”的相關(guān)知識(shí),小編通過實(shí)際案例向大家展示操作過程,操作方法簡單快捷,實(shí)用性強(qiáng),希望這篇“python apscheduler cron定時(shí)任務(wù)觸發(fā)接口自動(dòng)化巡檢如何實(shí)現(xiàn)”文章能幫助大家解決問題。
定時(shí)任務(wù)觸發(fā)方式有幾種類型,日常的工作中,研發(fā)同學(xué)運(yùn)用比較多的就是cron方式
查了一下APScheduler框架內(nèi)支持多種定時(shí)任務(wù)方式
首先先安裝apscheduler模塊
$ pip install apscheduler
代碼如下:(在方法內(nèi)注釋了各種時(shí)間參數(shù)的定義與范圍)
from apscheduler.schedulers.blocking import BlockingScheduler class Timing: def __init__(self, start_date, end_date, hour=None): self.start_date = start_date self.end_date = end_date self.hour = hour def cron(self, job, *value_list): """cron格式 在特定時(shí)間周期性地觸發(fā)""" # year (int 或 str) – 年,4位數(shù)字 # month (int 或 str) – 月 (范圍1-12) # day (int 或 str) – 日 (范圍1-31) # week (int 或 str) – 周 (范圍1-53) # day_of_week (int 或 str) – 周內(nèi)第幾天或者星期幾 (范圍0-6 或者 mon,tue,wed,thu,fri,sat,sun) # hour (int 或 str) – 時(shí) (范圍0-23) # minute (int 或 str) – 分 (范圍0-59) # second (int 或 str) – 秒 (范圍0-59) # start_date (datetime 或 str) – 最早開始日期(包含) # end_date (datetime 或 str) – 分 最晚結(jié)束時(shí)間(包含) # timezone (datetime.tzinfo 或str) – 指定時(shí)區(qū) scheduler = BlockingScheduler() scheduler.add_job(job, 'cron', start_date=self.start_date, end_date=self.end_date, hour=self.hour, args=[*value_list]) scheduler.start() def interval(self, job, *value_list): """interval格式 周期觸發(fā)任務(wù)""" # weeks (int) - 間隔幾周 # days (int) - 間隔幾天 # hours (int) - 間隔幾小時(shí) # minutes (int) - 間隔幾分鐘 # seconds (int) - 間隔多少秒 # start_date (datetime 或 str) - 開始日期 # end_date (datetime 或 str) - 結(jié)束日期 # timezone (datetime.tzinfo 或str) - 時(shí)區(qū) scheduler = BlockingScheduler() # 在 2019-08-29 22:15:00至2019-08-29 22:17:00期間,每隔1分30秒 運(yùn)行一次 job 方法 scheduler.add_job(job, 'interval', minutes=1, seconds=30, start_date=self.start_date, end_date=self.end_date, args=[*value_list]) scheduler.start() @staticmethod def date(job, *value_list): """date格式 特定時(shí)間點(diǎn)觸發(fā)""" # run_date (datetime 或 str) - 作業(yè)的運(yùn)行日期或時(shí)間 # timezone (datetime.tzinfo 或 str) - 指定時(shí)區(qū) scheduler = BlockingScheduler() # 在 2019-8-30 01:00:01 運(yùn)行一次 job 方法 scheduler.add_job(job, 'date', run_date='2019-8-30 01:00:00', args=[*value_list]) scheduler.start()
封裝的方法不是很通用,后面會(huì)優(yōu)化一下代碼,但最起碼現(xiàn)在是能用的,哈哈哈哈哈哈
思考了一下思路,巡檢觸發(fā)任務(wù),然后觸發(fā)釘釘,所以定時(shí)任務(wù)應(yīng)該是在最上層
之前分享的釘釘封裝的代碼內(nèi)底部繼續(xù)完善一下
if __name__ == '__main__': file_list = ["test_shiyan.py", "MeetSpringFestival.py"] # run_py(file_list) case_list = ["test_case_01", "test_case_02"] # run_case(test_sample, case_list) dingDing_list = [2, case_list, test_sample] # run_dingDing(*dingDing_list) Timing('2022-02-15 00:00:00', '2022-02-16 00:00:00', '0-23').cron(run_dingDing, *dingDing_list)
把run_dingDing()的函數(shù)我們放在已經(jīng)封裝好的Timing().cron(run_dingDing,*dingDing_list)內(nèi),那么run_dingDing()內(nèi)的參數(shù)我們通過元組的方式傳入
就是我們上面寫的這里能看到
def cron(self, job, *value_list): """cron格式 在特定時(shí)間周期性地觸發(fā)""" scheduler.add_job(job, 'cron', start_date=self.start_date, end_date=self.end_date, hour=self.hour, args=[*value_list])
時(shí)間范圍的填寫我放在了Timing()初始化內(nèi),看著舒服一點(diǎn)
在運(yùn)行Timing().cron()后就可以觸發(fā)定時(shí)了,但是必須要開著電腦才可以,等后面開始研究平臺(tái),存儲(chǔ)在服務(wù)器內(nèi)就美吱吱了~
apscheduler 運(yùn)行過程中出現(xiàn)類似如下報(bào)錯(cuò):
Run time of job "9668_hack (trigger: interval[1:00:00], next run at: 2018-10-29 22:00:00 CST)" was missed by 0:01:47.387821Run time of job "9668_index (trigger: interval[0:30:00], next run at: 2018-10-29 21:30:00 CST)" was missed by 0:01:47.392574Run time of job "9669_deep (trigger: interval[1:00:00], next run at: 2018-10-29 22:00:00 CST)" was missed by 0:01:47.397622Run time of job "9669_hack (trigger: interval[1:00:00], next run at: 2018-10-29 22:00:00 CST)" was missed by 0:01:47.402938Run time of job "9669_index (trigger: interval[0:30:00], next run at: 2018-10-29 21:30:00 CST)" was missed by 0:01:47.407996
針對(duì)該問題百度是基本上指不上了,google到了關(guān)鍵配置,但仍然出現(xiàn)該報(bào)錯(cuò),于是繼續(xù)找資料,刨根問底這到是什么鬼問題導(dǎo)致的。
里面說到了一個(gè)參數(shù):misfire_grace_time,但是這個(gè)參數(shù)到底是干嘛用的,在其他地方找到了解釋,其中涉及到幾個(gè)其他參數(shù),但是結(jié)合自己的理解綜合總結(jié)一下
coalesce
:當(dāng)由于某種原因?qū)е履硞€(gè)job積攢了好幾次沒有實(shí)際運(yùn)行(比如說系統(tǒng)掛了5分鐘后恢復(fù),有一個(gè)任務(wù)是每分鐘跑一次的,按道理說這5分鐘內(nèi)本來是“計(jì)劃”運(yùn)行5次的,但實(shí)際沒有執(zhí)行),如果coalesce為True,下次這個(gè)job被submit給executor時(shí),只會(huì)執(zhí)行1次,也就是最后這次,如果為False,那么會(huì)執(zhí)行5次(不一定,因?yàn)檫€有其他條件,看后面misfire_grace_time的解釋)
max_instance
:就是說同一個(gè)job同一時(shí)間最多有幾個(gè)實(shí)例再跑,比如一個(gè)耗時(shí)10分鐘的job,被指定每分鐘運(yùn)行1次,如果我們max_instance值為5,那么在第6~10分鐘上,新的運(yùn)行實(shí)例不會(huì)被執(zhí)行,因?yàn)橐呀?jīng)有5個(gè)實(shí)例在跑了
misfire_grace_time
:設(shè)想和上述coalesce類似的場(chǎng)景,如果一個(gè)job本來14:00有一次執(zhí)行,但是由于某種原因沒有被調(diào)度上,現(xiàn)在14:01了,這個(gè)14:00的運(yùn)行實(shí)例被提交時(shí),會(huì)檢查它預(yù)訂運(yùn)行的時(shí)間和當(dāng)下時(shí)間的差值(這里是1分鐘),大于我們?cè)O(shè)置的30秒限制,那么這個(gè)運(yùn)行實(shí)例不會(huì)被執(zhí)行。
示例:
15分鐘一次的的任務(wù),misfire_grace_time 設(shè)置100秒,在0:06分的時(shí)候提示:
Run time of job "9392_index (trigger: interval[0:15:00], next run at: 2018-10-27 00:15:00 CST)" was missed by 0:06:03.931026
解釋:
本來應(yīng)該在0:00執(zhí)行的任務(wù),某種原因沒有被調(diào)度,提示下次運(yùn)行(0:15)與當(dāng)前差了6分鐘(閾值100秒),所以0:15的時(shí)候?qū)⒉粫?huì)運(yùn)行
所以這個(gè)參數(shù)可以通俗的理解為任務(wù)的超時(shí)容錯(cuò)配置,給executor 一個(gè)超時(shí)時(shí)間,這個(gè)時(shí)間范圍內(nèi)要是該跑的還沒跑完,你TND的就別再跑了。
于是我修改了配置如下:
class Config(object): SCHEDULER_JOBSTORES = { 'default': RedisJobStore(db=3,host='0.0.0.0', port=6378,password='******'), } SCHEDULER_EXECUTORS = { 'default': {'type': 'processpool', 'max_workers': 50} #用進(jìn)程池提升任務(wù)處理效率 } SCHEDULER_JOB_DEFAULTS = { 'coalesce': True, #積攢的任務(wù)只跑一次 'max_instances': 1000, #支持1000個(gè)實(shí)例并發(fā) 'misfire_grace_time':600 #600秒的任務(wù)超時(shí)容錯(cuò) } SCHEDULER_API_ENABLED = True
我本以為這樣應(yīng)該就沒什么問題了,配置看似完美,但是現(xiàn)實(shí)是殘忍的,盯著apscheduler日志看了一會(huì),熟悉的“was missed by”又出現(xiàn)了,這時(shí)候就需要懷疑這個(gè)配置到底有沒有生效了,然后發(fā)現(xiàn)果然沒有生效,從/scheduler/jobs中可以看到任務(wù):
{ "id": "9586_site_status", "name": "9586_site_status", "func": "monitor_scheduler:monitor_site_status", "args": [ 9586, "http://sl.jxcn.cn/", 1000, 100, 200, "", 0, 2 ], "kwargs": {}, "trigger": "interval", "start_date": "2018-09-14T00:00:00+08:00", "end_date": "2018-12-31T00:00:00+08:00", "minutes": 15, "misfire_grace_time": 10, "max_instances": 3000, "next_run_time": "2018-10-24T18:00:00+08:00" }
可以看到任務(wù)中默認(rèn)就有misfire_grace_time配置,沒有改為600,折騰一會(huì)發(fā)現(xiàn)修改配置,重啟與修改任務(wù)都不會(huì)生效,只能修改配置后刪除任務(wù)重新添加(才能把這個(gè)默認(rèn)配置用上),或者修改任務(wù)的時(shí)候把這個(gè)值改掉
scheduler.modify_job(func=func, id=id, args=args, trigger=trigger, minutes=minutes,start_date=start_date,end_date=end_date,misfire_grace_time=600)
然后就可以了?圖樣圖森破,missed 依然存在。
其實(shí)從后來的報(bào)錯(cuò)可以發(fā)現(xiàn)這個(gè)容錯(cuò)時(shí)間是用上的,因?yàn)閺膱?zhí)行時(shí)間加上600秒后才出現(xiàn)的報(bào)錯(cuò)。
那么還是回到這個(gè)超時(shí)根本問題上,即使容錯(cuò)時(shí)間足夠長,沒有這個(gè)報(bào)錯(cuò)了,但是一個(gè)任務(wù)執(zhí)行時(shí)間過長仍然是個(gè)根本問題,所以終極思路還在于如何優(yōu)化executor的執(zhí)行時(shí)間上。
當(dāng)然這里根據(jù)不同的任務(wù)處理方式是不一樣的,在于各自的代碼了,比如更改鏈接方式、代碼是否有冗余請(qǐng)求,是否可以改為異步執(zhí)行,等等。
而我自己的任務(wù)解決方式為:由接口請(qǐng)求改為python模塊直接傳參,redis鏈接改為內(nèi)網(wǎng),極大提升執(zhí)行效率,所以也就控制了執(zhí)行超時(shí)問題。
關(guān)于“python apscheduler cron定時(shí)任務(wù)觸發(fā)接口自動(dòng)化巡檢如何實(shí)現(xiàn)”的內(nèi)容就介紹到這里了,感謝大家的閱讀。如果想了解更多行業(yè)相關(guān)的知識(shí),可以關(guān)注億速云行業(yè)資訊頻道,小編每天都會(huì)為大家更新不同的知識(shí)點(diǎn)。
免責(zé)聲明:本站發(fā)布的內(nèi)容(圖片、視頻和文字)以原創(chuàng)、轉(zhuǎn)載和分享為主,文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng),如果涉及侵權(quán)請(qǐng)聯(lián)系站長郵箱:is@yisu.com進(jìn)行舉報(bào),并提供相關(guān)證據(jù),一經(jīng)查實(shí),將立刻刪除涉嫌侵權(quán)內(nèi)容。