APScheduler本身不支持真正的分布式调度，仅为单进程内存级调度器。多实例下易导致任务重复或丢失，需借助Redis锁或改用Celery等专业方案实现高可用。
APScheduler本身不支持分布式，别被文档误导
APScheduler 的 BackgroundScheduler 和 BlockingScheduler 都是单进程内存级调度器，所有 job、trigger、state 全部存在 Python 进程内存里。一旦进程重启、机器宕机、或你启了多个实例——任务就重复执行、漏执行、状态丢失。官方文档里提的 “distributed deployments” 实际只是说“可以配合外部存储用”，不是开箱即用的分布式方案。
所以如果你在 k8s 里起了 3 个副本，每个都跑 BackgroundScheduler + SQLAlchemyJobStore，结果就是：3 个实例各自读取 job 表、各自触发、各自更新状态，根本不同步。
真正能落地的做法只有两种：要么彻底换掉 APScheduler，用 Celery + Redis/RabbitMQ + beat；要么用 APScheduler 做“本地轻量调度”，把“任务执行”和“调度决策”拆开，由外部协调器（如 Redis 锁 + 时间轮）来保证唯一性。
用 Redis 分布式锁 + APScheduler 实现“伪分布式”
这是中小团队最常走的折中路径：保留 APScheduler 的易用 API，但只让它负责“到点提醒”，真执行前加一层分布式的准入控制。核心逻辑是：APScheduler 每到触发时间就调用一个 wrapper 函数，该函数先尝试在 Redis 里抢一个带 TTL 的锁（key 格式如 lock:job:send_daily_report），抢到才执行业务逻辑。
立即学习“Python免费学习笔记（深入）”；
关键点：
-
redis-py必须用set(key, val, nx=True, ex=30)原子操作抢锁，不能先exists再set - 锁的 TTL 要明显大于任务最大执行时长（比如任务最长 10 秒，TTL 设为 60 秒），防止误释放
- APScheduler 的
trigger推荐用CronTrigger，避免IntervalTrigger在多实例下因启动时间差导致错峰触发 - 所有实例必须共享同一套
SQLAlchemyJobStore（如 PostgreSQL），否则 job 状态无法统一查看
示例 wrapper：
创建 Flask + Vue.js 全栈项目，采用单端口架构、uv 依赖管理、结构化日志和生产级前端设计。当用户要求以下操作时触发：创建新的 Flask+Vue 项目、搭建 Web 应用、构建全栈 Python+Vue 应用、初始化 Flask Web 项目、设置单端口 Flask 前后端项目。触发词：新建项目、创建项目、搭建项目、Flask项目、Vue项目。
def safe_run_job(job_func, job_id):
lock_key = f"lock:job:{job_id}"
if redis_client.set(lock_key, "1", nx=True, ex=60):
try:
job_func() # 真正的业务逻辑
finally:
redis_client.delete(lock_key)
else:
logger.debug(f"Job {job_id} skipped: lock not acquired")
为什么不用 APScheduler 的 MongoDB/RedisJobStore？
APScheduler 官方提供的 MongoDBJobStore 和第三方 RedisJobStore（如 apscheduler-jobstore-redis）只解决了 job 元数据的持久化，没解决并发调度问题。它们仍然依赖本地 scheduler 实例去轮询数据库查“哪些 job 到点了”，而轮询间隔（coalesce 和 max_instances 参数）在多实例场景下极易冲突。
典型症状：
- 两个实例同时查到同一个
next_run_time小于当前时间的 job - 都把它标记为
running，都开始执行 - 哪怕用了
max_instances=1，也只是限制单个实例内并发数，跨实例无效
换句话说：RedisJobStore 只是把内存 job 搬到了 Redis 里存，调度逻辑还是各干各的——它不是分布式调度器，只是一个“带远程存储的单机调度器”。
真正高可用的替代方案就两个
如果业务要求强一致性、失败自动重试、任务优先级、执行历史可追溯，APScheduler 不是合适选择。这时候应该明确切换：
-
Celery + Redis + celery-beat：celery-beat 是单点，但只负责“发任务”，worker 是无状态的，扩缩容自由；Redis 故障时 celery-beat 可配
schedule_filename降级为本地文件存储 - 专用调度服务：如 Quartz（Java）、Temporal（Go/Python SDK）、或者云厂商的定时函数（AWS EventBridge Scheduler、阿里云 Scheduling Service）——它们从设计上就分离了“调度平面”和“执行平面”
硬用 APScheduler 撑分布式，最后往往是在 Redis 锁、数据库行锁、自定义心跳表、job 状态补偿逻辑上反复填坑——这些工作量加起来，已经远超换成 Celery 的迁移成本。
记住：调度器的“高可用”不等于“多起几个进程”，而是“谁决定该执行、谁保证只执行一次、谁记录执行结果”。APScheduler 在第一个环节就缺原生支持。
