|
|
这几年断断续续在几个项目里用过 Celery，从最初的“能跑就行”到后面稳定扛量，踩过不少坑，也总结出一套朴素但好用的实践，分享给还在路上的同学。
先说选型与职责边界。Celery 天生适合做异步、可重试、对时延不那么敏感的后台作业，比如发送通知、生成报表、数据清洗；而不是实时强一致的订单扣库存那类强事务逻辑。把 Web 请求的关键链路和任务队列解耦，降低耦合点，心态就会平和许多。消息中间件建议优先 Redis（简单、足够快）或 RabbitMQ（路由能力强）。单实例 Redis 够用时别急着上哨兵与集群，复杂度是要付利息的；但提前留好配置切换位。
任务设计上，强调幂等和可重试。失败重试不是银弹，没有幂等支撑只会放大副作用。最基础的做法是为任务输入建立业务幂等键，在任务开头先查状态表；写外部世界（数据库、对象存储、三方 API）时做到“要么成功一次，要么可以安全重试”。重试策略别用线性重试刷屏，指数退避加抖动更温和，默认的 countdown 可以替换为 retry(countdown=backoff(i), jitter=rand)。同时给任务设置 hard/soft time limit，soft 超时里做清理，hard 超时兜底杀掉，避免“僵尸”耗死 worker。
序列化与大小控制也容易被忽略。默认 JSON 足够，大对象放存储只传引用，避免把 10MB 的 payload 塞进 broker。链式任务、和弦（chord）很香，但要留意结果回传风暴，必要时关闭结果存储或改用外部结果后端。生产上我更常把任务拆成可观测的独立步骤，用回调串起来，而不是一把梭的巨型 pipeline。
并发与并行策略，不要盲目把 worker 并发开到 CPU 核心数的数倍。I/O 密集型可以稍微放大，CPU 密集型优先用专用队列绑定单独进程池，甚至用 gevent/multiprocessing 分池隔离。把任务按“快/慢”“轻/重”分多个队列，热点接口发射到 fast 队列，重任务放 slow 队列，避免“慢任务拖死全队”。prefetch_count 勿设太大，避免任务被单 worker 抓太多导致延迟抖动。
可观测性方面，Flower 能看个大概，但生产还得接入日志与指标。日志里打印 task_id、幂等键、重试次数、耗时区间，把异常堆栈完整打出来。指标层面至少埋下入队速率、执行耗时 P95/P99、成功/失败/重试比、队列积压量、worker 心跳数，配合告警阈值。定位问题首看积压是否在增长，再看失败是否集中在某一任务或某一时间窗口。
部署与滚动更新也有门道。代码与 worker 要保持版本匹配，更新时先停旧 worker 再发布生产代码，最后启动新 worker，避免消费到新格式消息的老代码或反之。涉及任务签名或参数结构调整时，给任务加版本号或保留向后兼容期。Beat 定时任务建议与 worker 分离进程跑，避免被长任务饿死调度；定时策略尽量错峰，别把一小时的批处理全压在整点。
结果后端别轻易用数据库做海量结果存储，容易把主库打爆。倾向 Redis 短期存储配合任务内持久化业务结果。需要审计或幂等校验时，才把关键字段写入业务库的“任务状态表”。另外记得设置 result_expires 清理老结果，周期性清理 orphaned chord。
最后谈容灾与限流。第三方 API 抖动时，队列会迅速堆积，故建议对外部依赖加舱壁：每个依赖一个队列与一组限流 worker，设置 rate_limit 或在任务内实现令牌桶；必要时做快速失败与降级，避免拖垮整体。Broker 层面开启持久化队列与消息持久化，进程崩溃不丢任务；但也要接受“至少一次投递”的现实，用幂等去对冲。
Celery 足够强大，但真正让它稳定的不是某个“神配置”，而是上述这些工程化小决策叠加起来的韧性。如果要继续深入，可以翻官方文档和 Cookbook，文档入口放在这里：https://docs.celeryq.dev/ 。 |
|
发表于 
微信公众号
官方抖音号