我们有Azure Kubernetes集群在运行(DEV、TST、PRD上每个阶段一个(，我们需要几个Python脚本定期运行，这就是我们使用APScheduler(3.6.0(的目的。使用默认的内存作业存储。
然而，几天前，我发现APScheduler的行为与预期不同。它发生在所有三个阶段：
- 自2020年3月27日起，设置为每小时0分钟和30分钟运行的特定作业已在21:30至00:00之间停止运行
- 同一个作业在奇怪的时间运行，例如：15和：45，频率很高
- 作业被跳过，而它们被安排为每5分钟运行一次。日志显示"正在启动作业"，但没有说明以下内容，应该是：作业；x_job(触发器：cron[月=">'，日=">"，周=">"，小时=">"、分钟=",5,10,15,20,25,30,35,40,45,50,55']，下一次运行时间：2020-08-18 10:35:00UTC("；成功执行。有时会同时触发两次运行，但不一定是下一次运行
已采取但未达到预期结果的步骤：
增加process_pool_workers和thread_pool_max_workers的数量，并设置misfire_grace_time:
执行人thread_pool_max_workers：50process_pool_max_workers：20作业默认值job_defaults_coalize:Truejob_defaults_max_instances:3misfire_grace_time:120
- 在add_jobs中为调度程序和设置时区="UTC"。scheduler=BlockingScheduler(executors=executors，job_defaults=job_default，时区='UTC'(scheduler.add_job(launch_profile_job，CronTrigger.from_crontab(scheduler_config.profile_job(，时区='UTC'(
我也检查了集群的资源，但调度程序的CPU和内存甚至没有达到它们的极限。我们的平均活跃吊舱数也很低，只有25个，即使这样，这也会成为我们K8s集群的一个问题，启用了自动缩放。
这里有人知道可能发生了什么吗？
不要使用内存中的作业存储，而是使用Redis、mongo等持久性存储。，如果您需要在调度程序重新启动或应用程序崩溃时持久化作业，则必须选择持久化作业存储。
APscheduler支持以下持久性作业存储
- SQLAlchemy
- MongoDB
- Redis
- 重新思考DB
- ZooKeeper