Bagaimana untuk melaksanakan pemeriksaan automatik antara muka pencetus tugas berjadual python apscheduler cron

Pemeriksaan automatik antara muka pencetus tugas berjadual Python cron

Terdapat beberapa jenis kaedah pencetus tugas berjadual Dalam kerja harian, pelajar R&D menggunakan lebih banyak Ia adalah cron kaedah

Saya menyemak bahawa rangka kerja APScheduler menyokong berbilang kaedah tugas berjadual

Mula-mula pasang modul apscheduler

$ pip install apscheduler

Kodnya adalah seperti berikut: (Pelbagai ulasan dibuat dalam kaedah Definisi dan julat parameter masa)

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

Kaedah enkapsulasi tidak begitu universal Kod akan dioptimumkan kemudian, tetapi sekurang-kurangnya ia boleh digunakan sekarang, hahahahahahahahahahahahahahaha

Saya memikirkannya untuk. seketika, Pemeriksaan mencetuskan tugas, dan kemudian mencetuskan DingTalk, jadi tugas yang dijadualkan harus berada di lapisan atas

kod pakej DingTalk yang dikongsi sebelum dan di bahagian bawah terus meningkatkan fungsi run_dingDing()

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)

Kami meletakkannya dalam Timing().cron(run_dingDing, *dingDing_list), kemudian kami lulus parameter dalam run_dingDing() dalam bentuk tupel

, iaitu apa yang kami menulis di atas dan anda boleh melihatnya di sini

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

Saya meletakkan pengisian dalam julat masa dalam pemulaan Timing(), yang kelihatan lebih selesa

Masa boleh dicetuskan selepas menjalankan Timing() .cron(), tetapi ia mestilah Hanya hidupkan komputer Apabila anda mula menyelidik platform kemudian, ia akan menjadi bagus untuk menyimpannya dalam pelayan~

apscheduler melaporkan ralat: Masa menjalankan tugas &hellip. ;… larian seterusnya di: ……)” terlepas oleh

apscheduler Ralat yang serupa dengan yang berikut berlaku semasa proses berjalan:

Run time of job "9668_hack (pencetus: selang[1:00:00], larian seterusnya pada: 2018- 10-29 22:00:00 CST)" terlepas sebanyak 0:01:47.387821Masa jalankan kerja "9668_index (pencetus: selang[0: 30:00], larian seterusnya pada: 29-10-2018 21:30: 00 CST)" telah terlepas sebanyak 0:01:47.392574Masa jalankan kerja "9669_deep (pencetus: selang [1:00:00], larian seterusnya pada: 2018-10-29 22:00:00 CST)" telah terlepas pada 0:01:47.397622Masa jalankan kerja "9669_hack (cetus: selang [1:00:00], larian seterusnya pada: 2018-10-29 22:00:00 CST)" terlepas oleh 0:01:47.402938Masa jalankan kerja "9669_index (pencetus: selang [0:30:00], larian seterusnya pada: 2018-10-29 21:30:00 CST) " telah terlepas pada 0:01:47.407996

Baidu pada dasarnya tidak dapat menunjukkan masalah ini. Google menemui konfigurasi kunci, tetapi ralat masih berlaku, jadi saya terus mencari maklumat untuk mengetahui apa yang menyebabkan masalah ini.

parameter misfire_grace_time

Terdapat parameter yang disebut di dalamnya: misfire_grace_time, tetapi untuk apa parameter ini saya temui penjelasan di tempat lain, yang melibatkan untuk beberapa parameter lain, tetapi untuk meringkaskan berdasarkan pemahaman saya sendiri

• coalesce: Apabila atas sebab tertentu sesuatu kerja terkumpul beberapa kali dan sebenarnya tidak berjalan ( Contohnya, jika sistem pulih selepas turun selama 5 minit, terdapat tugas yang berjalan sekali setiap minit Secara logiknya, ia "dirancang" untuk berjalan 5 kali dalam 5 minit ini, tetapi ia sebenarnya tidak dilaksanakan). lain kali Apabila tugas ini diserahkan kepada pelaksana, ia hanya akan dilaksanakan sekali, iaitu kali terakhir Jika Salah, ia akan dilaksanakan sebanyak 5 kali (tidak semestinya, kerana terdapat syarat lain, lihat penjelasan misfire_grace_time. kemudian)

• max_instance: Ini bermakna kerja yang sama boleh mempunyai sehingga beberapa kejadian pada masa yang sama Contohnya, kerja yang mengambil masa 10 minit ditetapkan untuk dijalankan sekali seminit. Jika nilai max_instance kami ialah 5, Kemudian pada minit ke-6 hingga ke-10, tika berjalan baharu tidak akan dilaksanakan kerana sudah ada 5 kejadian berjalan

• misfire_grace_time: Bayangkan senario yang serupa dengan gabungan di atas , jika kerja pada asalnya dilaksanakan pada 14:00, tetapi tidak dijadualkan atas sebab tertentu, dan kini 14:01, apabila contoh berjalan 14:00 diserahkan, ia akan menyemaknya masa berjalan berjadual dan masa semasa Jika perbezaan (di sini ialah 1 minit) lebih besar daripada had 30 saat yang kami tetapkan, maka contoh larian ini tidak akan dilaksanakan.

Contoh:

Untuk tugasan sekali setiap 15 minit, misfire_grace_time ditetapkan kepada 100 saat dan gesaan pada 0:06:

Masa jalankan kerja "9392_index (pencetus: selang [0:15:00], larian seterusnya pada: 2018-10-27 00:15:00 CST)" terlepas sebanyak 0:06:03.931026

Penjelasan:

• Tugas yang sepatutnya dilaksanakan pada 0:00 tidak dijadualkan atas sebab tertentu dan telah digesa untuk dijalankan kali seterusnya ( 0:15) adalah 6 minit berbeza daripada masa semasa (ambang 100 saat), jadi ia tidak akan berjalan pada 0:15

• , jadi parameter ini boleh lazimnya difahami sebagai toleransi tamat masa tugas Konfigurasikan dan berikan pelaksana tempoh tamat Jika perkara yang sepatutnya dijalankan belum selesai dalam julat masa ini, TND anda harus berhenti berjalan.

Jadi saya mengubah suai konfigurasi seperti berikut:

 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链接改为内网，极大提升执行效率，所以也就控制了执行超时问题。

Atas ialah kandungan terperinci Bagaimana untuk melaksanakan pemeriksaan automatik antara muka pencetus tugas berjadual python apscheduler cron. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!