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 持久化策略——这些细节藏在配置深处，但决定系统能不能挺过流量高峰或网络抖动。
