python cron定時(shí)任務(wù)觸發(fā)接口自動(dòng)化巡檢

定時(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ù)我們通過(guò)元組的方式傳入

就是我們上面寫的這里能看到

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報(bào)錯(cuò)：Run time of job …… next run at: ……)” was missed by

apscheduler 運(yùn)行過(guò)程中出現(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ì)該問(wèn)題百度是基本上指不上了，google到了關(guān)鍵配置，但仍然出現(xiàn)該報(bào)錯(cuò)，于是繼續(xù)找資料，刨根問(wèn)底這到是什么鬼問(wèn)題導(dǎo)致的。

misfire_grace_time參數(shù)

google 到的是github上的一個(gè)issue：https://github.com/agronholm/apscheduler/issues/146

里面說(shuō)到了一個(gè)參數(shù)：misfire_grace_time，但是這個(gè)參數(shù)到底是干嘛用的，在其他地方找到了解釋，其中涉及到幾個(gè)其他參數(shù)，但是結(jié)合自己的理解綜合總結(jié)一下

• coalesce：當(dāng)由于某種原因?qū)е履硞€(gè)job積攢了好幾次沒(méi)有實(shí)際運(yùn)行（比如說(shuō)系統(tǒng)掛了5分鐘后恢復(fù)，有一個(gè)任務(wù)是每分鐘跑一次的，按道理說(shuō)這5分鐘內(nèi)本來(lái)是“計(jì)劃”運(yùn)行5次的，但實(shí)際沒(méi)有執(zhí)行），如果coalesce為True，下次這個(gè)job被submit給executor時(shí)，只會(huì)執(zhí)行1次，也就是最后這次，如果為False，那么會(huì)執(zhí)行5次（不一定，因?yàn)檫€有其他條件，看后面misfire_grace_time的解釋）
• max_instance：就是說(shuō)同一個(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本來(lái)14:00有一次執(zhí)行，但是由于某種原因沒(méi)有被調(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  

解釋：

• 本來(lái)應(yīng)該在0：00執(zhí)行的任務(wù)，某種原因沒(méi)有被調(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)要是該跑的還沒(mé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)該就沒(méi)什么問(wèn)題了，配置看似完美，但是現(xiàn)實(shí)是殘忍的，盯著apscheduler日志看了一會(huì)，熟悉的“was missed by”又出現(xiàn)了，這時(shí)候就需要懷疑這個(gè)配置到底有沒(méi)有生效了，然后發(fā)現(xiàn)果然沒(méi)有生效，從/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配置，沒(méi)有改為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í)從后來(lái)的報(bào)錯(cuò)可以發(fā)現(xiàn)這個(gè)容錯(cuò)時(shí)間是用上的，因?yàn)閺膱?zhí)行時(shí)間加上600秒后才出現(xiàn)的報(bào)錯(cuò)。

找到任務(wù)超時(shí)的根本原因

那么還是回到這個(gè)超時(shí)根本問(wèn)題上，即使容錯(cuò)時(shí)間足夠長(zhǎng)，沒(méi)有這個(gè)報(bào)錯(cuò)了，但是一個(gè)任務(wù)執(zhí)行時(shí)間過(guò)長(zhǎng)仍然是個(gè)根本問(wèn)題，所以終極思路還在于如何優(yōu)化executor的執(zhí)行時(shí)間上。

當(dāng)然這里根據(jù)不同的任務(wù)處理方式是不一樣的，在于各自的代碼了，比如更改鏈接方式、代碼是否有冗余請(qǐng)求，是否可以改為異步執(zhí)行，等等。

而我自己的任務(wù)解決方式為：由接口請(qǐng)求改為python模塊直接傳參，redis鏈接改為內(nèi)網(wǎng)，極大提升執(zhí)行效率，所以也就控制了執(zhí)行超時(shí)問(wèn)題。

總結(jié)

以上為個(gè)人經(jīng)驗(yàn)，希望能給大家一個(gè)參考，也希望大家多多支持腳本之家。

最新評(píng)論