Es gibt verschiedene Arten von Methoden zur Auslösung geplanter Aufgaben. In der täglichen Arbeit verwenden F&E-Studenten häufiger die Cron-Methode. Ich habe überprüft, dass das APScheduler-Framework mehrere Methoden zur Auslösung geplanter Aufgaben unterstützt
Installieren Sie zuerst das Apscheduler-Modul
$ pip install apscheduler
Der Code lautet wie folgt: (Die Definitionen und Bereiche verschiedener Zeitparameter sind in der Methode mit Anmerkungen versehen)
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格式 在特定时间周期性地触发"""
# year (int 或 str) – 年，4位数字
# month (int 或 str) – 月 (范围1-12)
# day (int 或 str) – 日 (范围1-31)
# week (int 或 str) – 周 (范围1-53)
# day_of_week (int 或 str) – 周内第几天或者星期几 (范围0-6 或者 mon,tue,wed,thu,fri,sat,sun)
# hour (int 或 str) – 时 (范围0-23)
# minute (int 或 str) – 分 (范围0-59)
# second (int 或 str) – 秒 (范围0-59)
# start_date (datetime 或 str) – 最早开始日期(包含)
# end_date (datetime 或 str) – 分 最晚结束时间(包含)
# timezone (datetime.tzinfo 或str) – 指定时区
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格式 周期触发任务"""
# weeks (int) - 间隔几周
# days (int) - 间隔几天
# hours (int) - 间隔几小时
# minutes (int) - 间隔几分钟
# seconds (int) - 间隔多少秒
# start_date (datetime 或 str) - 开始日期
# end_date (datetime 或 str) - 结束日期
# timezone (datetime.tzinfo 或str) - 时区
scheduler = BlockingScheduler()
# 在 2019-08-29 22:15:00至2019-08-29 22:17:00期间，每隔1分30秒 运行一次 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格式 特定时间点触发"""
# run_date (datetime 或 str) - 作业的运行日期或时间
# timezone (datetime.tzinfo 或 str) - 指定时区
scheduler = BlockingScheduler()
# 在 2019-8-30 01:00:01 运行一次 job 方法
scheduler.add_job(job, 'date', run_date='2019-8-30 01:00:00', args=[*value_list])
scheduler.start()Die Kapselungsmethode ist nicht sehr universell und der Code wird später optimiert. Aber immerhin ist es jetzt brauchbar, hahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahaha hahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahaha unten
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)Wir fügen die Funktion von run_dingDing() in das gekapselte Timing().cron(run_dingDing, *dingDing_list) ein und übergeben dann die Parameter in run_dingDing() in Form von Tupeln
Es ist das, was wir oben geschrieben haben Hier können Sie sehen
def cron(self, job, *value_list):
"""cron格式 在特定时间周期性地触发"""
scheduler.add_job(job, 'cron', start_date=self.start_date, end_date=self.end_date, hour=self.hour,
args=[*value_list])Ich habe die Füllung in den Zeitbereich in der Timing()-Initialisierung eingefügt, was es komfortabler macht
Das Timing kann nach dem Ausführen von Timing().cron() ausgelöst werden, aber der Computer muss es sein aktiviert. Okay, wenn Sie später mit der Erforschung der Plattform beginnen, ist es schön, sie auf dem Server zu speichern~
apscheduler error: Run time of job …… next run at: ……)“ wurde verpasst
apscheduler während der Ausführung Es erscheint ein Fehler ähnlich dem folgenden:
Laufzeit des Jobs „9668_hack (Auslöser: Intervall[1:00:00], nächste Ausführung um: 29.10.2018 22:00:00 CST) " wurde um 0:01 verfehlt: 47.387821 Die Laufzeit des Jobs „9668_index (Trigger: Intervall[0:30:00], nächste Ausführung am: 29.10.2018 21:30:00 CST)" wurde um 0:01 verfehlt :47.392574Laufzeit des Jobs „9669_deep (Trigger: Intervall[1:00:00], nächste Ausführung am: 29.10.2018 22:00:00 CST)“ wurde um 0:01:47.397622 verpasst.Laufzeit des Jobs „ 9669_hack (Trigger: Interval[1: 00:00], nächster Lauf am: 29.10.2018 22:00:00 CST)“ wurde um 0:01:47.402938 verpasst. Laufzeit des Jobs „9669_index (Trigger: Interval[0 :30:00], nächster Lauf am: 29.10.2018 21:30:00 CST)“ wurde um 0:01:47.407996 verpasstBaidu konnte im Grunde nicht auf dieses Problem hinweisen. Google hat die Schlüsselkonfiguration gefunden, aber der Fehler ist immer noch aufgetreten, also suchen Sie weiter nach Informationen und finden Sie heraus, was zum Teufel dieses Problem verursacht.
misfire_grace_time-ParameterDa ist ein Parameter erwähnt: misfire_grace_time, aber wofür wird dieser Parameter verwendet? Ich habe an anderer Stelle eine Erklärung gefunden, die mehrere andere Parameter betrifft, aber ich werde sie nach meinem eigenen Verständnis zusammenfassen.
coalesce: Wenn sich ein Job aus irgendeinem Grund mehrmals ansammelt und nicht tatsächlich ausgeführt wird (z. B. wenn das System hängt und sich dann nach 5 Minuten erholt), gibt es eine Aufgabe, die jede Minute ausgeführt wird , es liegt nahe, dass es „geplant“ war, in diesen 5 Minuten fünfmal auszuführen, aber nicht tatsächlich ausgeführt wurde). , das ist das letzte Mal, wenn es False ist, wird es fünfmal ausgeführt (nicht unbedingt, da es andere Bedingungen gibt, siehe die Erklärung von misfire_grace_time später) max_instance: Das Das heißt, wie oft kann derselbe Job gleichzeitig ausgeführt werden? Ein Job, der 10 Minuten dauert, wird beispielsweise einmal pro Minute ausgeführt. dann wird die neue laufende Instanz 6 bis 10 Minuten lang nicht ausgeführt, da bereits 5 Minuten ausgeführt werden. Eine Instanz wird ausgeführt um 14:00 Uhr, war aber aus irgendeinem Grund nicht geplant, jetzt 14:01 Uhr. Wenn diese um 14:00 Uhr laufende Instanz übermittelt wird, wird die Differenz zwischen ihrer geplanten Laufzeit und der aktuellen Zeit (hier ist 1 Minute) überprüft Wenn sie größer als das von uns festgelegte 30-Sekunden-Limit ist, wird diese laufende Instanz nicht ausgeführt. coalesce：当由于某种原因导致某个job积攒了好几次没有实际运行（比如说系统挂了5分钟后恢复，有一个任务是每分钟跑一次的，按道理说这5分钟内本来是“计划”运行5次的，但实际没有执行），如果coalesce为True，下次这个job被submit给executor时，只会执行1次，也就是最后这次，如果为False，那么会执行5次（不一定，因为还有其他条件，看后面misfire_grace_time的解释）
max_instance：就是说同一个job同一时间最多有几个实例再跑，比如一个耗时10分钟的job，被指定每分钟运行1次，如果我们max_instance值为5，那么在第6~10分钟上，新的运行实例不会被执行，因为已经有5个实例在跑了
misfire_grace_time
Eine Aufgabe, die alle 15 Minuten auftritt, misfire_grace_time ist auf 100 Sekunden eingestellt und die Eingabeaufforderung erscheint bei 0:06:
Laufzeit des Jobs „9392_index (Trigger: Intervall[0: 15:00 ], nächster Lauf am: 27.10.2018 00:15:00 CST)“ wurde um 0:06:03.931026 verpasst
Erklärung:
Eine Aufgabe, die bei 0 hätte ausgeführt werden sollen :00, irgendwie Der Grund ist nicht geplant, was dazu führt, dass sich der nächste Lauf (0:15) 6 Minuten vom aktuellen unterscheidet (Schwellenwert 100 Sekunden), sodass er nicht bei 0:15 ausgeführt wird
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} #用进程池提升任务处理效率
}
SCHEDULER_JOB_DEFAULTS = {
'coalesce': True, #积攒的任务只跑一次
'max_instances': 1000, #支持1000个实例并发
'misfire_grace_time':600 #600秒的任务超时容错
}
SCHEDULER_API_ENABLED = True我本以为这样应该就没什么问题了，配置看似完美，但是现实是残忍的，盯着apscheduler日志看了一会，熟悉的“was missed by”又出现了，这时候就需要怀疑这个配置到底有没有生效了，然后发现果然没有生效，从/scheduler/jobs中可以看到任务：
{
"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"
}可以看到任务中默认就有misfire_grace_time配置，没有改为600，折腾一会发现修改配置，重启与修改任务都不会生效，只能修改配置后删除任务重新添加（才能把这个默认配置用上），或者修改任务的时候把这个值改掉
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 依然存在。
其实从后来的报错可以发现这个容错时间是用上的，因为从执行时间加上600秒后才出现的报错。
那么还是回到这个超时根本问题上，即使容错时间足够长，没有这个报错了，但是一个任务执行时间过长仍然是个根本问题，所以终极思路还在于如何优化executor的执行时间上。
当然这里根据不同的任务处理方式是不一样的，在于各自的代码了，比如更改链接方式、代码是否有冗余请求，是否可以改为异步执行，等等。
而我自己的任务解决方式为：由接口请求改为python模块直接传参，redis链接改为内网，极大提升执行效率，所以也就控制了执行超时问题。
Das obige ist der detaillierte Inhalt vonSo implementieren Sie die automatische Überprüfung der Triggerschnittstelle für geplante Aufgaben in Python Apscheduler Cron. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!
![[Web-Frontend] Node.js-Schnellstart](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
