在 Django 中使用 django_apscheduler 实现定时任务, 发现报错如下:
Run time of job "9668_hack (trigger: interval[1:00:00], next run at: 2018-10-29 22:00:00 CST)" was missed by 0:01:47.387821
Run time of job "9668_index (trigger: interval[0:30:00], next run at: 2018-10-29 21:30:00 CST)" was missed by 0:01:47.392574
解决方案：
在 scheduler里增加一个参数：misfire_grace_time。
这个参数可以通俗的理解为任务的超时容错配置，给executor一个超时时间，这个时间范围内，没有正常跑的还可以继续跑，直到跑了；要是该跑的还没跑完，就别再跑了。
这个参数的大小设置一般是在 job was missed by 0:01:47.402938 这里看，任务是在 1 分钟左右检测到丢失的，所以可以设置为 5 分钟，即 300s 。
检测到任务丢失的时间是在指定时间后的 1min，所以在 5min 里足以检测到丢失的任务再运行一次。
scheduler.add_job(
my_job, 'cron', id='task_time',
day_of_week='mon-fri', hour='18', minute='24',
misfire_grace_time=300
)
其他参数来辅助理解：
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秒限制，那么这个运行实例不会被执行。