Python 分布式任务调度的选型地图

celery 是多数 python 分布式任务调度场景中“踩坑成本最低”的起点，因其成熟、文档全、中间件支持广、与 django/flask 集成顺畅；常见问题包括 broker 与 result 后端不一致、序列化配置错误、redis 持久化缺失等。

Celery 为什么还是最常被选中的那个

Celery 不是唯一选择，但它是多数 Python 分布式任务调度场景里“踩坑成本最低”的起点。它成熟、文档全、中间件支持广（rabbitmq、Redis、apache kafka 都能接），而且和 Django/Flask 集成几乎无痛。

常见错误现象：Worker 启动后不消费任务，大概率是 BROKER_URL 和 result_backend 指向了不同实例，或 task_serializer 与 result_serializer 不一致导致反序列化失败。

• 默认用 json 序列化，别轻易切 pickle——跨版本或异构服务时会出 AttributeError: Can't get attribute
• CELERY_TASK_ACKS_LATE = True 要配合 worker_prefetch_multiplier = 1，否则高并发下可能丢任务
• 如果只用 Redis 做 broker，注意它不保证消息持久化；生产环境务必配 redis://...?socket_keepalive=True 防连接漂移

想轻量？RQ + Redis 是真快上手

RQ（Redis Queue）适合中小团队快速落地「异步通知」「报表生成」这类确定性高、失败容忍度高的任务。它没有 Celery 那套 broker/worker/result 的抽象分层，代码就三行：定义函数、enqueue、启 rqscheduler 或 rq worker。

使用场景：用户注册后发邮件、上传文件后触发压缩、定时清理日志。

立即学习“Python免费学习笔记（深入）”；

• RQ 不支持任务重试策略（如指数退避），得自己在函数里包 try/except + job.retry()
• 所有任务必须是模块顶层函数，不能是类方法或闭包，否则反序列化报 AttributeError: 'module' Object has no attribute 'xxx'
• Redis 内存吃紧时，rq info 显示队列长度为 0 但任务卡在 deferred 状态——其实是 job 对象被 LRU 淘汰了，得调大 maxmemory-policy 或换 allkeys-lru

需要强一致性或复杂依赖？别硬刚 Celery，试试 Dramatiq

Dramatiq 强制要求消息幂等、默认启用中间件重试、原生支持任务优先级和延迟执行，且整个设计围绕「至少一次投递 + 幂等处理」展开。它比 Celery 更早默认关闭 auto-ack，天然规避消息丢失。

性能影响：Dramatiq 的 actor 模型让任务定义更紧凑，但 broker 必须用 RabbitMQ 或 Redis（Redis 下不支持延迟队列原子性）；用 RabbitMQ 时，每个 actor 对应一个 queue，队列数膨胀快。

• 别直接把 datetime 对象传进 send_with_options，会报 TypeError: Object of type datetime is not JSON serializable，先转 isoformat()
• retry_when 回调函数必须返回布尔值，返回 None 就等于永远不重试
• 和 Flask 集成时，dramatiq.set_broker 必须在应用初始化完成之后调，否则 BrokerNotSetError

为什么 Airflow 通常不是“任务调度”而是“工作流编排”

Airflow 的核心不是跑单个异步任务，而是管理有上下游依赖、需重试/告警/血缘追踪的 DAG。它自带 ui、调度器、元数据库、Executor 抽象，但这也意味着：哪怕只跑一个定时脚本，也要搭 DB、起 webserver、维护 scheduler 进程。

容易踩的坑：把 Airflow 当 RQ/Celery 用，结果发现 PythonOperator 执行慢、日志查起来绕、小任务启动开销比实际运行还高。

• schedule_interval 设成 @hourly，但任务实际触发时间取决于上一轮是否完成——它不是 cron，是“上一轮结束 + interval 后再触发”
• 本地调试用 airflow tasks test，别用 trigger_dag，后者走完整调度链路，容易误触生产配置
• catchup=False 必须显式设，否则补历史数据时可能并发拉爆下游 API

分布式调度这件事，最难的从来不是“怎么跑起来”，而是“怎么知道它没悄悄失败”。监控埋点、任务幂等、重试边界、broker 持久化策略——这些细节藏在配置深处，但决定系统能不能挺过流量高峰或网络抖动。