APScheduler 不适合分布式定时任务，因其无法协调多节点执行权，会导致任务重复触发；推荐使用 Celery Beat + Redis 或 redbeat 方案，它们通过消息队列和原子锁确保单次触发；K8s CronJob 仅适用于无状态、短时批处理任务。
用 APScheduler 做分布式定时任务？别试了
它天生不支持多节点协调，多个实例会重复触发同一任务。哪怕加了 SQLAlchemyJobStore，也只是持久化 job 定义，不解决执行权竞争——两个进程同时查到「该跑了」，就真的一起跑。
常见错误现象：job executed twice、数据库里 jobs 表没变但日志疯狂刷、任务幂等性被反复挑战。
使用场景：你有 2 台 Web 服务器，想让 send_daily_report 每天早上 9 点只执行一次。
- APScheduler 适合单机轻量调度，比如脚本内定时拉日志、开发环境模拟 cron
- 一旦部署到多实例（K8s Pod / 多台 EC2 / Gunicorn 多 worker），必须换方案
- 它的
coalesce=True和max_instances=1对跨进程无效
立即学习“Python免费学习笔记（深入）”；
Celery Beat + Redis 是最稳的落地组合
不是因为它多高级，而是它把「谁来触发」和「谁来执行」拆开了：celery beat 是唯一调度器，只发任务消息；celery worker 负责消费，天然支持多实例并发处理，且 Redis 的原子操作能守住调度边界。
关键配置点：
-
BROKER_URL = "redis://localhost:6379/0"—— 必须用 Redis，RabbitMQ 不保证 beat 的调度一致性 -
CELERYBEAT_SCHEDULER = "celery.beat:PersistentScheduler"—— 启用本地持久化，避免 beat 进程重启丢任务 - 任务函数必须用
@app.task装饰，不能是普通函数，否则 worker 收不到 - 时间用
crontab(minute="0", hour="9")，别用timedelta，后者在多时区下容易漂移
示例片段：
from celery import Celery
<p>app = Celery("tasks", broker="redis://localhost:6379/0")
app.conf.beat_schedule = {
"send-daily-report": {
"task": "tasks.send_daily_report",
"schedule": "0 0 <em> </em> *", # 注意：这是 crontab 格式，不是秒数
}
}
如果已有 Redis 但不想上 Celery？直接用 redbeat
它是 Celery 的插件，但把调度逻辑全搬到 Redis 里，连 celery beat 进程都省了——所有 worker 自己抢锁、自己判断是否该触发，更轻、更易扩缩容。
性能影响小，因为抢锁用的是 SET key value NX EX 60，毫秒级；兼容性好，只要 Celery 版本 ≥ 5.0 就行。
- 安装：
pip install redbeat - 配置里加一行：
redbeat_redis_url = "redis://localhost:6379/1"（建议单独 DB 避免干扰） - 调度定义改写成：
app.conf.redbeat_schedule = { ... }，结构和beat_schedule一样 - 注意：所有 worker 必须用相同
redbeat_key_prefix，否则互相看不见锁
为什么不用 Kubernetes CronJob？
它适合「跑完就退出」的批处理，比如每天备份数据库。但如果你的任务要长期运行、需要状态反馈、或依赖 Python 运行时上下文（比如 Django ORM、Flask app context），K8s CronJob 就很吃力——每次启动新容器，得重新加载整个环境，失败重试难控制，日志分散，没法和主服务共享连接池。
典型踩坑：
- 任务里调
django.db.connection，报DatabaseWrapper objects created in a thread can't be used in another thread - 用
requests.Session()复用连接，但 CronJob 每次都是新进程，完全失效 - 想看上次执行结果？得手动存到外部存储，不如直接走 Celery 的
result backend
真正需要 K8s CronJob 的场景，其实是和主应用解耦的运维任务，比如清理临时文件、导出审计日志到 S3。
