用 RabbitMQ 优先选 Celery，因其与 AMQP 深度耦合，重试、优先级、延迟队列开箱即用；若仅用 Redis 且无需复杂调度，则 Dramatiq 启动快、内存低、无 worker 管理负担。
选 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 自动化像说话一样简单 —— 用代码控制你的 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 以为任务失败，其实只是结果查不到。
立即学习“Python免费学习笔记（深入）”；
- 必须分库：
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) 只删队列里的待执行项，正在跑的任务完全不受影响。
- 真要中断长任务，得在业务代码里定期检查
self.is_aborted()（Celery）或主动轮询 Redis 中某个 flag key - 不要依赖框架级取消做超时控制——用
soft_time_limit+time_limit更可靠 - 异步任务里启动子进程（如调用 ffmpeg）？取消信号默认不透传，得手动
os.killpg，否则变成僵尸进程
