python多任务框架 _ Python多任务框架Celery、Dramatiq与RQ对比与使用-Python教程-PHP中文网

用 RabbitMQ 优先选 Celery，因其与 AMQP 深度耦合，重试、优先级、延迟队列开箱即用；若仅用 Redis 且无需复杂调度，则 Dramatiq 启动快、内存低、无 worker 管理负担。

python多任务框架 _ python多任务框架celery、dramatiq与rq对比与使用

选 Celery 还是 Dramatiq？先看你的消息队列有没有 RabbitMQ

如果你的基础设施里已经跑着 RabbitMQ，Celery 是最稳妥的选择——它和 RabbitMQ 的 AMQP 协议深度耦合，任务重试、优先级、延迟队列都开箱即用。但反过来，如果你只用 Redis，Celery 就会绕过很多原生能力（比如 Redis Streams 的有序消费），靠自己模拟，容易出时序 bug。

Dramatiq 默认只认 Redis（通过 redis-py），设计上强制“一次投递、不重试”，靠中间件做幂等；它不支持 RabbitMQ，也没打算支持。所以不是“哪个更好”，而是“你手里的消息中间件能不能被它直连”。

用 RabbitMQ → 优先 Celery，别硬套 Dramatiq
只用 Redis 且不需要复杂调度 → Dramatiq 启动快、内存占用低、无后台 worker 进程管理负担
Redis 版本 Dramatiq 的 redis-locks 可能因 Lua 脚本兼容性失败，得降级到 dramatiq[redis]

RQ 为什么适合小项目但扛不住高并发

RQ（Redis Queue）本质是把 Redis 当作任务列表 + 状态存储，没独立 broker 层，worker 直接 BLPOP 拉任务。好处是部署极简：装个 rq、起一个 rq worker 就能跑；坏处是所有 worker 共享同一组 Redis 连接，当并发任务 > 500/秒，BLPOP 频繁唤醒 + 序列化开销会让 Redis CPU 暴涨，且无法按队列限流。

macOS UI 自动化技能包 —— 用 Python 控制你的 Mac

让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限

下载

适合场景：celery beat 类定时任务少、单次任务耗时 > 1s、日均任务量
别在 RQ 里塞 pickle 序列化的大型对象——Redis 带宽和反序列化时间都会成瓶颈
想加重试？得自己写 @job(retry=3) 逻辑，RQ 自带的 retry 只支持固定间隔，不能退避（exponential backoff）

Celery 的配置陷阱：broker_url 和 result_backend 别混用同一个 Redis DB

很多人图省事，把 broker_url 和 result_backend 都设成 redis://localhost:6379/0，结果发现任务状态总丢、AsyncResult.get() 返回 None。原因是 Celery 用不同 key pattern 存消息和结果，但 Redis 的 KEYS * 扫描、FLUSHDB 或某些运维脚本会一锅端——broker 消息还在，result 却清空了，worker 以为任务失败，其实只是结果查不到。

必须分库：broker_url = "redis://localhost:6379/1"，result_backend = "redis://localhost:6379/2"
如果用 Redis Cluster，Celery 不支持——它依赖单节点的 Pub/Sub 和 Lua 原子操作，集群模式下会报 ClusterDownError
task_serializer = "json" 是底线，别用 pickle，否则跨 Python 版本或 worker 重启后反序列化直接 AttributeError

三个框架对“任务取消”的实际支持程度很有限

文档里写的 revoke、cancel 大多只是标记“别再执行”，不是真杀进程。Celery 的 revoke(terminate=True) 依赖信号（SIGTERM），但 Python 的 signal handler 在 GIL 下可能延迟数秒；Dramatiq 根本不提供取消 API；RQ 的 queue.cancel_job(job_id) 只删队列里的待执行项，正在跑的任务完全不受影响。