APScheduler 3.0.1浅析

简介

APScheduler是一个小巧而强大的Python类库，通过它你可以实现类似Unix系统cronjob类似的定时任务系统。使用之余，阅读一下源码，一方面有助于更好的使用它，另一方面，个人认为aps的架构设计质量很高，阅读它对于提升软件开发的sense很有帮助。

组成

APScheduler整个系统可以说由这五个概念组成：

• scheduler：控制器，可以看做整个系统的driver，外部世界通过它来实现任务（Job）的增删改查管理。根据IO模式的不同，aps提供了多种scheduler实现。
• job：描述一个任务本身。
• jobstore：任务持久化仓库。aps提供了内存、redis、mongodb、sqlalchemy几种store
• executor：执行任务的模块。根据不同的IO模型有多种executor选择。
• trigger：描述一个任务何时被触发，有按日期、按时间间隔、按cronjob描述式三种触发方式

这样的划分充分发挥了软件设计中抽象的威力，我们下面对每个模块进行描述

scheduler

BaseScheduler类是所有scheduler的抽象基类，它的初始化代码是这样的：

     def __init__(self, gconfig={}, **options):
         super(BaseScheduler, self).__init__()
         self._executors = {}
         self._executors_lock = self._create_lock()
         self._jobstores = {}
         self._jobstores_lock = self._create_lock()
         self._listeners = []
         self._listeners_lock = self._create_lock()
         self._pending_jobs = []
         self.configure(gconfig, **options)

可以看到一个scheduler维护了自己的executor和jobstore表，通过configure方法进行初始化。在configure中，scheduler读取传入的配置，对executors和jobstores进行初始化，一个典型的配置是这样的：

 APS_SCHEDULER_CONFIG = {
     'jobstores': {
         'default': {'type': 'sqlalchemy', 'url': 'postgres://127.0.0.1:5432/optimus'},
     },
     'executors': {
         'default': {'type': 'processpool', 'max_workers': 10}
     },
     'job_defaults': {
         'coalesce': True,
         'max_instances': 5,
         'misfire_grace_time': 30
     },
     'timezone': 'Asia/Shanghai'
 }

如果我们把APS_SCHEDULER_CONFIG作为options传入给一个scheduler，会产生什么结果呢？首先，我们添加了一个默认(名叫default)的jobstore，它的具体实现类型是sqlalchemy，数据库连接url是指向一个本地postgresql数据库，也就是说添加到这个scheduler的job会默认使用这个jobstore进行存储。其次，我们添加了一个默认的executor，他是一个多进程实现，也就是说每个job在运行时，是通过一个进程池来作为worker实际执行的，这个进程池最大size是10。job_defaults参数定义了一些特殊行为：

• 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：设想和上述coalesce类似的场景，如果一个job本来14:00有一次执行，但是由于某种原因没有被调度上，现在14:01了，这个14:00的运行实例被提交时，会检查它预订运行的时间和当下时间的差值（这里是1分钟），大于我们设置的30秒限制，那么这个运行实例不会被执行。

这里还需要指出的一点是，为什么scheduler的配置可以写成这种json形式，而scheduler会正确地找到对应的实现类进行初始化？这里运用了两个技巧：

entry point

用python egg的机制把各个组件注册了成了entry point，如下所示

 [apscheduler.executors]
 asyncio = apscheduler.executors.asyncio:AsyncIOExecutor
 debug = apscheduler.executors.debug:DebugExecutor
 gevent = apscheduler.executors.gevent:GeventExecutor
 processpool = apscheduler.executors.pool:ProcessPoolExecutor
 threadpool = apscheduler.executors.pool:ThreadPoolExecutor
 twisted = apscheduler.executors.twisted:TwistedExecutor

 [apscheduler.jobstores]
 memory = apscheduler.jobstores.memory:MemoryJobStore
 mongodb = apscheduler.jobstores.mongodb:MongoDBJobStore
 redis = apscheduler.jobstores.redis:RedisJobStore
 sqlalchemy = apscheduler.jobstores.sqlalchemy:SQLAlchemyJobStore

 [apscheduler.triggers]
 cron = apscheduler.triggers.cron:CronTrigger
 date = apscheduler.triggers.date:DateTrigger
 interval = apscheduler.triggers.interval:IntervalTrigger

这样，在scheduler模块中就可以用entry point的名称反查出对应组件

     _trigger_plugins = dict((ep.name, ep) for ep in iter_entry_points('apscheduler.triggers'))
     _trigger_classes = {}
     _executor_plugins = dict((ep.name, ep) for ep in iter_entry_points('apscheduler.executors'))
     _executor_classes = {}
     _jobstore_plugins = dict((ep.name, ep) for ep in iter_entry_points('apscheduler.jobstores'))
     _jobstore_classes = {}
     _stopped = True

从而实现了一个便利的插件机制

ref_to_obj

另外通过一个加载函数完成"apscheduler.executors.pool:ThreadPoolExecutor"字符串到ThreadPoolExecutor类对象的查询

 def ref_to_obj(ref):
     """
     Returns the object pointed to by ``ref``.

     :type ref: str
     """

     if not isinstance(ref, six.string_types):
         raise TypeError('References must be strings')
     if ':' not in ref:
         raise ValueError('Invalid reference')

     modulename, rest = ref.split(':', 1)
     try:
         obj = __import__(modulename)
     except ImportError:
         raise LookupError('Error resolving reference %s: could not import module' % ref)

     try:
         for name in modulename.split('.')[1:] + rest.split('.'):
             obj = getattr(obj, name)
         return obj
     except Exception:
         raise LookupError('Error resolving reference %s: error looking up object' % ref)

 

scheduler的主循环（main_loop），其实就是反复检查是不是有到时需要执行的任务，完成一次检查的函数是_process_jobs, 这个函数做这么几件事：

1. 询问自己的每一个jobstore，有没有到期需要执行的任务（jobstore.get_due_jobs()）
2. 如果有，计算这些job中每个job需要运行的时间点（run_times = job._get_run_times(now)）如果run_times有多个，这种情况我们上面讨论过，有coalesce检查
3. 提交给executor排期运行（executor.submit_job(job, run_times)）

那么在这个_process_jobs的逻辑，什么时候调用合适呢？如果不间断地调用，而实际上没有要执行的job，是一种浪费。每次掉用_process_jobs后，其实可以预先判断一下，下一次要执行的job（离现在最近的）还要多长时间，作为返回值告诉main_loop, 这时主循环就可以去睡一觉，等大约这么长时间后再唤醒，执行下一次_process_jobs。这里唤醒的机制就会有IO模型的区别了

scheduler由于IO模型的不同，可以有多种实现，如

• BlockingScheduler：main_loop就在当前进程的主线程内运行，所以调用start函数后会阻塞当前线程。通过一个threading.Event条件变量对象完成scheduler的定时唤醒。
• BackgroundScheduler：和BlockingScheduler基本一样，除了main_loop放在了单独线程里，所以调用start后主线程不会阻塞
• AsyncIOScheduler：使用asyncio作为IO模型的scheduler，和AsyncIOExecutor配合使用，用asynio中event_loop的call_later完成定时唤醒
• GeventScheduler：和BlockingScheduler基本一样，使用gevent作为IO模型，和GeventExecutor配合使用
• QtScheduler：使用QTimer完成定时唤醒
• TornadoScheduler：使用tornado的IO模型，用ioloop.add_timeout完成定时唤醒
• TwistedScheduler：配合TwistedExecutor，用reactor.callLater完成定时唤醒

JobStore

jobstore提供给scheduler一个序列化jobs的统一抽象，提供对scheduler中job的增删改查接口，根据存储backend的不同，分以下几种

• 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，完成一次实际的任务实例执行。以线程/进程池实现为例

     def _do_submit_job(self, job, run_times):
         def callback(f):
             exc, tb = (f.exception_info() if hasattr(f, 'exception_info') else
                        (f.exception(), getattr(f.exception(), '__traceback__', None)))
             if exc:
                 self._run_job_error(job.id, exc, tb)
             else:
                 self._run_job_success(job.id, f.result())

         f = self._pool.submit(run_job, job, job._jobstore_alias, run_times, self._logger.name)
         f.add_done_callback(callback)

Trigger

trigger是抽象出了“一个job是何时被触发”这个策略，每种trigger实现自己的get_next_fire_time函数

     @abstractmethod
     def get_next_fire_time(self, previous_fire_time, now):
         """
         Returns the next datetime to fire on, If no such datetime can be calculated, returns ``None``.

         :param datetime.datetime previous_fire_time: the previous time the trigger was fired
         :param datetime.datetime now: current datetime
         """

aps提供的trigger包括：

• date：一次性指定日期
• interval：在某个时间范围内间隔多长时间执行一次
• cron：和unix crontab格式兼容，最为强大

总结

简要介绍了apscheduler类库的组成，强调抽象概念的理解

 

转载于:https://www.cnblogs.com/quijote/p/4385774.html