Python apscheduler cron 예약 작업 트리거 인터페이스의 자동 검사를 구현하는 방법

Python cron 예약 작업 트리거 인터페이스 자동 검사

일상 작업에서 R&D 학생들은 cron 메서드를 더 자주 사용합니다.

APScheduler 프레임워크가 여러 예약 작업 메서드를 지원하는지 확인했습니다.

먼저 apscheduler 모듈을 설치하세요

$ pip install apscheduler

코드는 다음과 같습니다. (다양한 시간 매개변수의 정의와 범위는 메서드에 주석으로 표시되어 있습니다.)

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()

캡슐화 방법은 그다지 보편적이지 않으며 코드는 나중에 최적화될 예정입니다. but at least Now it is usable, hahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahaha.com with some thought, patrol inspection triggers the task, and then triggers DingTalk, so the scheduled task should be in the top layer

The DingTalk package code shared before and continue to be improved at 하단

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)

캡슐화된 Timing().cron(run_dingDing, *dingDing_list)에 run_dingDing() 함수를 넣은 다음 run_dingDing()에 튜플 형식으로 매개변수를 전달합니다

위에서 작성한 내용입니다 여기에서

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])

Timing() 초기화에 시간 범위를 채워넣었기 때문에 더 편안해졌습니다.

Timing().cron()을 실행한 후에 타이밍이 트리거될 수 있지만 컴퓨터는 반드시 좋아요, 나중에 플랫폼 조사를 시작할 때 서버에 저장하면 좋을 것 같아요~

apscheduler 오류: 작업 실행 시간 …… 다음 실행 시간: ……)'이 누락되었습니다.

apscheduler 실행 중 다음과 유사한 오류가 나타납니다.

작업 실행 시간 "9668_hack(트리거: 간격[1:00:00], 다음 실행 시간: 2018-10-29 22:00:00 CST) "가 0:01에 누락되었습니다. 47.387821"9668_index 작업의 실행 시간(트리거: 간격[0:30:00], 다음 실행 시간: 2018-10-29 21:30:00 CST)"이 0:01에 누락되었습니다. :47.392574"9669_deep(트리거: 간격[1:00:00], 다음 실행 시간: 2018-10-29 22:00:00 CST)" 작업의 실행 시간이 0:01:47.397622작업 실행 시간에 누락되었습니다. 9669_hack(트리거: 간격[1: 00:00], 다음 실행 시간: 2018-10-29 22:00:00 CST)"가 0:01:47.402938 작업의 실행 시간 "9669_index(트리거: 간격[0)에 의해 누락되었습니다. :30:00], 다음 실행 시간: 2018-10-29 21:30:00 CST)"는 0:01:47.407996

Baidu에서 기본적으로 이 문제를 지적할 수 없었습니다. Google은 핵심 구성을 찾았습니다. 하지만 오류는 계속 발생하므로 계속해서 정보를 찾아 이 문제의 원인이 무엇인지 알아보세요.

misfire_grace_time 매개변수

거기에 언급된 매개변수가 있습니다: misfire_grace_time, 그런데 이 매개변수는 무엇에 사용됩니까? 다른 여러 매개변수와 관련된 설명을 다른 곳에서 찾았지만 제가 이해한 내용을 바탕으로 요약하겠습니다.

coalesce: 어떤 이유로 작업이 여러 번 누적되고 실제로 실행되지 않는 경우(예: 시스템이 중단되었다가 5분 후에 복구되는 경우, 1분마다 실행되는 작업이 있음) , 이 5분 동안 5번 실행되도록 "계획"되었지만 실제로 실행되지는 않았습니다.) Coalesce가 True이면 다음 번에 작업이 실행자에 제출될 때 한 번만 실행됩니다. , 이것이 마지막입니다. False이면 5번 실행됩니다. (반드시 그런 것은 아니며, 다른 조건이 있으므로 나중에 misfire_grace_time 설명을 참조하세요.)

• 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

  max_instance: 즉 즉, 동일한 작업이 동시에 몇 번이나 다시 실행될 수 있습니까? 예를 들어, max_instance 값이 5인 경우 10분 동안 실행되는 작업이 지정됩니다. 그러면 이미 5개의 인스턴스가 실행 중이므로 새 실행 중인 인스턴스는 6~10분 동안 실행되지 않습니다. 인스턴스가 실행 중입니다.

misfire_grace_time: 작업이 원래 있었던 경우와 유사한 시나리오를 상상해 보세요. 14:00에 실행되었지만 어떤 이유로 예약되지 않았으므로 현재 14:01입니다. 이 14:00 실행 인스턴스가 제출되면 예약된 실행 시간과 현재 시간(여기서는 1분) 간의 차이가 확인됩니다. 설정한 30초 제한보다 크면 실행 중인 인스턴스가 실행되지 않습니다.

예:

15분마다 발생하는 작업, misfire_grace_time은 100초로 설정되고 0:06에 프롬프트:

작업 실행 시간 "9392_index(트리거: 간격[0:15: 00 ], 다음 실행 시간: 2018-10-27 00:15:00 CST)"가 0:06:03.931026

• 설명:

• 0:00에 실행되어야 하는 작업입니다. , 어떤 종류의 이유가 예약되지 않아 다음 실행(0:15)이 현재 실행(임계값 100초)과 6분 다르므로 0:15

에 실행되지 않습니다. 따라서 이 매개변수는 작업 시간 초과 내결함성 구성은 실행자에게 시간 초과 기간을 제공하므로 널리 사용되는 방식으로 이해됩니다. 실행해야 할 작업이 이 시간 범위 내에 완료되지 않으면 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}  #用进程池提升任务处理效率
    }
 
    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链接改为内网，极大提升执行效率，所以也就控制了执行超时问题。

위 내용은 Python apscheduler cron 예약 작업 트리거 인터페이스의 자동 검사를 구현하는 방법의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!