简介
APScheduler:强大的任务调度工具,可以完成定时任务,周期任务等,它是跨平台的,用于取代Linux下的cron daemon或者Windows下的task scheduler。
内置三种调度调度系统:
Cron风格
间隔性执行
仅在某个时间执行一次
作业存储的backends支持:
Memory
SQLAlchemy (any RDBMS supported by SQLAlchemy works)
MongoDB
Redis
RethinkDB
ZooKeeper
基本概念:4个组件
triggers: 描述一个任务何时被触发,有按日期、按时间间隔、按cronjob描述式三种触发方式
job stores: 任务持久化仓库,默认保存任务在内存中,也可将任务保存都各种数据库中,任务中的数据序列化后保存到持久化数据库,从数据库加载后又反序列化。
executors: 执行任务模块,当任务完成时executors通知schedulers,schedulers收到后会发出一个适当的事件
schedulers: 任务调度器,控制器角色,通过它配置job stores和executors,添加、修改和删除任务。
插件机制: 供用户自由选择scheduler, job store(s), executor(s) and trigger(s)
scheduler
scheduler的主循环(main_loop),其实就是反复检查是不是有到时需要执行的任务,完成一次检查的函数是_process_jobs, 这个函数做这么几件事:
询问自己的每一个jobstore,有没有到期需要执行的任务(jobstore.get_due_jobs())
如果有,计算这些job中每个job需要运行的时间点(run_times = job._get_run_times(now))如果run_times有多个,这种情况我们上面讨论过,有coalesce检查
提交给executor排期运行(executor.submit_job(job, run_times))
那么在这个_process_jobs的逻辑,什么时候调用合适呢?如果不间断地调用,而实际上没有要执行的job,是一种浪费。每次掉用_process_jobs后,其实可以预先判断一下,下一次要执行的job(离现在最近的)还要多长时间,作为返回值告诉main_loop, 这时主循环就可以去睡一觉,等大约这么长时间后再唤醒,执行下一次_process_jobs。这里唤醒的机制就会有IO模型的区别了
scheduler由于IO模型的不同,可以有多种实现,内置scheduler供选:
BlockingScheduler: scheduler在当前进程的主线程中运行,所以调用start函数会阻塞当前线程,不能立即返回。
BackgroundScheduler: 放到后台线程中运行,所以调用start后主线程不会阻塞
AsyncIOScheduler: 使用asyncio模块
GeventScheduler: 使用gevent作为IO模型,和GeventExecutor配合使用
TornadoScheduler: 配合TwistedExecutor,用reactor.callLater完成定时唤醒
TwistedScheduler: 使用tornado的IO模型,用ioloop.add_timeout完成定时唤醒
QtScheduler: 使用QTimer完成定时唤醒
jobstore
jobstore提供给scheduler一个序列化jobs的统一抽象,提供对scheduler中job的增删改查接口,根据存储backend的不同,分以下几种
内置job stores供选:
MemoryJobStore:没有序列化,jobs就存在内存里,增删改查也都是在内存中操作
SQLAlchemyJobStore:所有sqlalchemy支持的数据库都可以做为backend,增删改查操作转化为对应backend的sql语句
MongoDBJobStore:用mongodb作backend
RedisJobStore: 用redis作backend
除了MemoryJobStore外,其他几种都使用pickle做序列化工具,所以这里要指出一点,如果你不是在用内存做jobstore,那么必须确保你提供给job的可执行函数必须是可以被全局访问的,也就是可以通过ref_to_obj反查出来的,否则无法序列化。
使用数据库做jobstore,就会发现,其实创建了一张有三个域的的jobs表,分别是****id, next_run_time, job_state,其中job_state是job对象pickle序列化后的二进制**,而id和next_run_time则是支持job的两类查询(按id和按最近运行时间)
executor
aps把任务最终的执行机制也抽象了出来,可以根据IO模型选配,不需要讲太多,最常用的是threadpool和processpoll两种(来自concurrent.futures的线程/进程池)。
不同类型的executor实现自己的_do_submit_job,完成一次实际的任务实例执行。以线程/进程池实现为例
内置executors供选:
ProcessPoolExecutor: 多进程,可指定进程数,当工作负载为CPU密集型操作时可以考虑使用它来利用多核CPU
ThreadPoolExecutor: 多线程,可指定线程数,默认,可以满足大多数用途
AsyncIOExecutor
DebugExecutor
GeventExecutor
ProcessPoolExecutor
ThreadPoolExecutor
TwistedExecutor
trigger
trigger是抽象出了“一个job是何时被触发”这个策略,每种trigger实现自己的get_next_fire_time函数
aps提供的trigger包括:
date:一次性指定日期
interval:在某个时间范围内间隔多长时间执行一次
cron:和unix crontab格式兼容,最为强大
默认配置: 使用MemoryJobStore和ThreadPoolExecutor
优点:插件化思想和抽象出接口,策略与不同实现机制分离
User guide
配置scheduler
官网提供了等价的三种方法,第一种比较简洁明了。
from pytz import utc
from apscheduler.schedulers.background import BackgroundScheduler
from apscheduler.jobstores.mongodb import MongoDBJobStore
from apscheduler.jobstores.sqlalchemy import SQLAlchemyJobStore
from apscheduler.executors.pool import ThreadPoolExecutor, ProcessPoolExecutor
jobstores = {
'mongo': MongoDBJobStore(),
'default': SQLAlchemyJobStore(url='sqlite:///jobs.sqlite')
}
executors = {
'default': ThreadPoolExecutor(20),
'processpool': ProcessPoolExecutor(5)
}
job_defaults = {
'coalesce': False,
'max_instances': 3
}
scheduler = BackgroundScheduler(jobstores=jobstores, executors=executors, job_defaults=job_defaults, timezone=utc)
from apscheduler.schedulers.background import BackgroundScheduler
# 使用默认配置,即MemoryJobStore和ThreadPoolExecutor(10)
scheduler = BackgroundScheduler()
启动调度器
调用调度器的start()方法
添加任务
两种方式:
调用调度器的add_job()
使用调度器的scheduled_job()装饰器: 很简洁,推荐这种。
其他的不常用操作如移除任务、暂停和恢复任务、获取调度了的任务列表、修改任务、关停调度器、暂停/恢复任务处理等见文档:http://apscheduler.readthedocs.io/en/latest/userguide.html
限制并发执行的任务实例数量
默认同一时刻只能有一个实例运行,通过max_instances=3修改为3个。
错过执行的任务与合并
misfire_grace_time:如果一个job本来14:00有一次执行,但是由于某种原因没有被调度上,现在14:01了,这个14:00的运行实例被提交时,会检查它预订运行的时间和当下时间的差值(这里是1分钟),大于我们设置的30秒限制,那么这个运行实例不会被执行。
合并:最常见的情形是scheduler被shutdown后重启,某个任务会积攒了好几次没执行如5次,下次这个job被submit给executor时,执行5次。将coalesce=True后,只会执行一次
Scheduler 事件
监听Scheduler发出的事件并作出处理,如任务执行完、任务出错等
def my_listener(event):
if event.exception:
print('The job crashed :(') # or logger.fatal('The job crashed :(')
else:
print('The job worked :)')
scheduler.add_listener(my_listener, EVENT_JOB_EXECUTED | EVENT_JOB_ERROR)