apscheduler 本身不支持分布式，需通过 redisjobstore 或数据库 + 外部锁实现轻量级分布式调度，但无法替代 celery beat 等专业方案。
APScheduler 本身不支持分布式
APScheduler 是单进程定时任务调度器，BackgroundScheduler 和 BlockingScheduler 都只在当前 Python 进程内生效。多个实例同时运行时，同一任务会被重复触发——这不是“没配好”，而是设计如此。
常见错误现象：job executed twice、日志里看到同一任务在不同机器上几乎同时打印；使用 SQLAlchemyJobStore 后仍重复执行，是因为没关掉本地内存缓存或没统一调度器角色。
- 必须禁用
MemoryJobStore（默认存在），显式配置外部存储 - 所有节点必须共用同一套
jobstore（如 PostgreSQL / Redis），且开启coalesce=True - 不能依赖
trigger的本地时间计算逻辑做跨节点对齐，要用 UTC 时间 + 外部锁保障唯一性
用 RedisJobStore 实现轻量级分布式调度
RedisJobStore 不是 APScheduler 官方内置组件，需通过 apscheduler[redis] 安装，并配合 redis-py 使用。它比 SQL 方案延迟更低，适合秒级 / 分钟级任务，但不保证强一致性。
使用场景：中小规模服务、无严格事务要求、能容忍极短时间窗口内的重复（如发通知、刷新缓存）。
立即学习 “Python 免费学习笔记（深入）”；
- 连接参数必须包含
jobs_key和run_times_key，否则多个实例会写冲突 - 务必设置
redis_url="redis://localhost:6379/1"显式指定 DB，避免和其他业务混用 - 启动时加
replace_existing=True，防止旧 job 残留导致调度混乱 - Redis 节点宕机时，APScheduler 会静默失败，建议搭配
try/except包裹add_job并记录告警
from apscheduler.jobstores.redis import RedisJobStore jobstores = {'default': RedisJobStore( jobs_key='apscheduler.jobs', run_times_key='apscheduler.run_times', host='localhost', port=6379, db=1) }用数据库 + 外部锁防重复执行
仅靠 SQLAlchemyJobStore 无法阻止并发执行，因为 APScheduler 只管“存 job”，不管“谁来跑”。真正防重得靠应用层加锁，比如用数据库唯一约束或 Redis SETNX。
性能影响：每次任务触发前多一次 DB/Redis 请求；兼容性上，PostgreSQL 的 ON CONFLICT DO NOTHING 比 MySQL 的 INSERT IGNORE 更可靠。
- 不要在
func内直接加锁——任务可能被中断，锁未释放 - 推荐在 job 触发入口处用
SELECT …… FOR UPDATE或 Redis 锁 + 过期时间（如 300 秒） - 锁 key 命名必须含 job_id + 执行时间戳（如
f"lock:{job_id}:{int(time.time() // 60)}"），避免不同周期任务互锁 - APScheduler 的
max_instances=1在分布式下完全无效，别信文档里那句“限制并发数”
为什么不用 Celery Beat 替代？
如果已有 Celery，celery beat 确实更适合作为分布式定时调度器——它天然支持多节点选举、任务分发、结果追踪。但切换成本高：要重写任务函数为 @app.task、引入消息队列、处理失败重试策略。
容易踩的坑：celery beat 本身不执行任务，只是发消息；若 worker 全挂，定时消息堆积在 broker 中，恢复后可能集中爆发；而 APScheduler + Redis 方案至少能保证“不发”。
- 纯定时 + 简单逻辑（如每 5 分钟调一次 HTTP 接口），APScheduler 扩展够用
- 需要任务链、重试、优先级、或和现有 Celery 流程整合，就别硬撑，切过去
- 别试图让 APScheduler“假装”是 Celery：比如用
add_job去发celery.send_task，这只会把问题从调度层转移到执行层
分布式调度真正的复杂点不在怎么存 job，而在“谁有资格执行”和“执行失败后怎么兜底”。这两个问题，APScheduler 不提供答案，得你自己用锁、状态表、心跳机制补全。
