第1章：Celery 术语全景与分布式任务架构原理

1. 项目背景我们是一家电商公司的订单履约与促销中台团队。每天早上十点运维群里都会飘红下单接口 P99 从 80ms 涨到 4.8 秒用户在小红书上吐槽「点完付款转圈半分钟」。查日志发现罪魁祸首是下单流程里的三个「顺手的」同步调用——发短信验证码、扣减库存、给财务写审计流水全部内联在 HTTP 请求里每个都要等第三方响应。用户点击「立即购买」 │ ▼ 下单接口同步阻塞 4.8s ├── 调短信网关 ──► 等待 2.5s ← 网关限流排队 ├── 扣减库存 ──► 等待 1.2s ← 数据库行锁竞争 └── 写审计日志 ──► 等待 1.1s ← 落库 I/O │ ▼ 返回「支付成功」用户已经等疯了痛点来看有三层同步阻塞短信网关一旦超时整个下单链路跟着超时前端 502用户以为钱扣了其实没扣客诉率飙升。失败无重试短信网关偶发 5xx代码里只有try...except log短信丢了就丢了订单状态和通知状态永远对不上运营每天拿 Excel 手动补发。削峰无门大促 10 倍流量时短信网关每秒最多接 200 条而同步调用会把全部流量直接怼上去把三方系统直接打挂。我们需要的是把「非即时必达」的动作从请求链路里拆出去扔进一个可靠、可重试、可排队的异步管道——这就是 Celery 要解决的问题。但引入 Celery 之前团队必须先统一一套语言什么叫 App什么叫 TaskWorker 和 Broker 到底谁是谁本章就先把这套语系建起来并画出全链路架构图。2. 项目设计三人开选题会小胖、小白、大师。主题——「我们真要用 Celery 吗它到底是个啥」小胖啃着薯片我翻了下官网说 Celery 是个「分布式任务队列」。这不就跟食堂打饭排队一样吗前面的人打好饭走了后面的人往前挪。我们要发短信就往队尾塞一个号服务员worker按顺序叫号完事儿为啥还要搞那么多名词什么 Broker、Backend 的听着像华尔街。小白推了推眼镜我觉得没那么简单。排队有一个关键问题食堂窗口如果突然挂掉了队伍里那些还没打饭的人怎么办谁替他们记住「这个人要一荤一素」而且打饭是同步的——你在窗口前必须等着菜出来。我们的短信任务要的是「提交后 2 秒内返回成功」人可以去干别的这才叫异步。大师喝了口茶小白点到要害了。Celery 的「队」和你想象的食堂队有个本质区别食堂的队伍只存在于你的大脑里而 Celery 的队伍存在于一个独立的中间件里。这个中间件叫Broker消息代理。生产端把任务作为一条消息写进去Broker 负责保存消费端Worker自己去取。所以食堂窗口挂了队伍还在——因为队伍存在 Broker 里不在窗口里。这就叫解耦。技术映射食堂队伍 消息队列食堂窗口 Worker 进程菜谱 任务定义Task「一荤一素」的约定 消息协议。小胖哦那谁来打饭是不是那个叫 Worker 的家伙我看一个 Worker 还能开好几个进程是不是窗口开得多打得就快大师对但 Worker 只是执行的那部分。整个系统还有三个角色要分清生产者你的 Web 进程负责点菜下单、Broker传菜口/冰箱暂存任务消息、Worker后厨真正执行任务。而「做完之后结果放哪」这个事Broker 不管得另找一个地方叫Result Backend结果后端——通常是个 Redis 或数据库存任务的状态和返回值。传菜口只负责传菜不负责帮你记账记账是财务室Backend的事。小白那消息真的不会丢吗Web 把任务写进 Broker如果这时候 Broker 挂了或者 Worker 取走消息后还没执行完就崩了任务不就没了我们扣库存的任务可是丢了就要出大事的。大师好问题这正是可靠性设计的分水岭。Celery 里消息的可靠性靠两个机制一是 Broker 的持久化——RabbitMQ 可以把消息落盘Redis 可以持久化 List二是确认机制Ack——Worker 取走消息后要么立刻告诉 Broker「我收到了」early ack要么执行完再告诉「我干完了」late ackacks_late。选错一个要么丢任务要么任务重复执行。从本章起你每遇到一个概念都要问自己它会不会丢会不会重这就是分布式任务的两大心魔。至于具体怎么配第 11 章讲重试幂等、第 18 章讲晚确认我们后面慢慢拆。技术映射早确认 食堂窗口先收单再炒菜单子不丢但菜炒糊了要重做晚确认 炒完菜才划单菜一定好但窗口崩溃时同一道菜可能被炒两遍。小胖眼睛一亮那我明白了下单发短信就是Web 写个「任务单」丢进 Broker 的柜子里 → Worker 从柜子里取出来执行 → 干完把结果写进 Backend。我发短信之前还能先看看订单 30 分钟没支付让「闹钟」Beat到点提醒我去关单对不对大师完全正确你已经把 Celery 最核心的六件套都摸到了App整个系统的总管家、Task任务定义、Broker消息暂存、Worker执行者、Backend结果存储、Beat定时闹钟。再补两个Queue/Exchange消息该进哪个柜子、按什么规则分柜和Canvas把多个任务拼成流水线/扇出/汇总的编排语法。这九个词就是全专栏 40 章的词典。今天下午我们把它们做成一张架构图 一份术语表全员对齐之后再聊代码。3. 项目实战本专栏「实战为主、理论为辅」。第 1 章的实战目标有两个① 画出一张「下单后发短信」的全链路架构图② 产出一份全员对齐的术语表沉淀到团队 Wiki。为了不让实战流于「画 PPT」我们先跑一个 10 分钟的小实验用真实代码验证「架构图里的每个框在 Celery 里都有实体对应」。3.1 环境准备Python 3.11Celery 5.6.2 要求 3.9Celery 5.6.2 源码本仓库后续第 2 章详解安装本步不需要启动任何 Broker纯代码内省python-cimport celery; print(celery.__version__)# 预期输出 5.6.2第 2 章我们才安装 Broker 和 Worker本章的验证全部发生在「创建 App」这一步不依赖外部服务。3.2 分步实现步骤 1创建 App查看默认队列实体目标验证「App 是配置与组件的根」并且默认队列叫celery。# introspect_app.pyfromceleryimportCelery appCelery(orders,brokerredis://localhost:6379/0)# 架构图中的「Queue」实体默认队列print(默认队列:,list(app.amqp.queues.keys()))print(默认交换机:,app.amqp.default_exchange.name)print(默认序列化:,app.conf.task_serializer)print(默认结果后端:,app.conf.result_backend)运行结果节选默认队列: [celery] 默认交换机: celery 默认序列化: json 默认结果后端: redis://localhost:6379/0步骤 2查看任务注册表验证「Task 是注册在 App 上的」目标证明app.task会把函数包装成Task实例并登记在app.tasks字典里。# introspect_app.py追加app.taskdefsend_order_sms(order_id:int)-None:print(f模拟发送订单{order_id}的短信)print(任务注册表:,list(app.tasks.keys()))print(任务类型:,type(app.tasks[__main__.send_order_sms]))运行结果任务注册表: [celery.accumulate, celery.backend_cleanup, celery.chain, celery.chord, celery.chunks, ..., __main__.send_order_sms] 任务类型: class celery.app.task.Task注意注册表里不仅有我们自己的任务还有celery.chain、celery.chord这些内置任务——它们正是架构图里 Canvas 编排能力的载体后面第 19、36 章会拆开讲。步骤 3输出「下单发短信」全链路架构图目标把术语落到图上形成团队 Wiki 的第一份资产。┌──────────── 调用方 ────────────┐ │ Web 下单接口 / 管理后台 / CLI │ 生产端 └──────────────┬─────────────────┘ │ send_order_sms.delay(order_id) ▼ ┌─────────────────────────────┐ │ Broker消息代理 │ 消息暂存RabbitMQ / Redis │ Queue: celery默认队列│ 持久化 确认 └──────────────┬──────────────┘ │ Kombu 消费 ▼ ┌─────────────────────────────┐ │ Worker执行者 │ 消费 → trace 执行 → 写结果 │ prefork 多进程 / 任务执行 │ └──────────────┬──────────────┘ │ 状态 / 返回值 ▼ ┌─────────────────────────────┐ │ Result Backend结果后端 │ Redis / RPC / DB │ 状态: PENDING→SUCCESS │ └─────────────────────────────┘ 旁路Beat定时闹钟│ Events监控事件│ Flower控制台把上面这张 ASCII 图 3.4 节的术语表存成docs/celery-glossary.md用一句话收尾「Web 只负责把任务消息交给 BrokerWorker 负责执行Backend 负责记账Beat 负责叫醒。」步骤 4运行验证python introspect_app.py预期输出包含「默认队列: [‘celery’]」与「任务类型: class ‘celery.app.task.Task’」全部打印成功即通过。3.3 可能遇到的坑及解决方法坑现象解决list(app.tasks.keys())里没有自己的任务只写了def send_order_sms没加app.task或装饰器后加了多余的括号未调用确认装饰器写法app.task任务必须在import 过的模块里定义任务注册名带奇怪前缀打印出celery.chain等内置任务误以为代码写错了正常现象celery.*是框架内置任务用于 Canvas 编排Windows 下运行卡住后续章节启动 Worker 时在 Windows 需要--poolsolo第 3 章会专门给 Windows 读者的启动参数忘记 3.6 之前版本的大小写查资料看到CELERY_TASK_SERIALIZER全大写5.x 已改为小写命名空间task_serializer第 4 章详解3.4 完整清单与测试验证本章「完整代码清单」即上文的introspect_app.pyGit 仓库本专栏配套代码将在第 40 章综合实战给出统一仓库。团队 Wiki 术语表节选全员对齐用术语一句话定义源码位置App系统的总管家配置/任务/组件都挂在它身上celery/app/base.pyTask被app.task包装的函数可跨进程调用的执行单元celery/app/task.pyWorker消费 Broker 消息并执行任务的进程celery/worker/Broker消息暂存与投递的中间件RabbitMQ/Rediscelery/app/amqp.pyBackend任务状态与结果存储celery/result.py、celery/backends/Queue消息队列默认叫celerycelery/app/defaults.pyAckWorker 对 Broker 的消息确认早确认/晚确认第 18 章详讲ETA任务约定执行时间countdown/eta第 21 章详讲Canvas任务编排原语chain/group/chordcelery/canvas.pyBeat定时调度器到点向 Broker 发任务celery/beat.pyIdempotent任务可重复执行而结果一致重试前提第 11 章详讲测试验证用 pytest 把「术语与实体的对应关系」固化成断言后续每章都复用这个测试目录# test_glossary.pyfromintrospect_appimportappdeftest_default_queue_is_celery():assertlist(app.amqp.queues.keys())[celery]deftest_task_registered():assert__main__.send_order_smsinapp.tasksdeftest_default_serializer_is_json():assertapp.conf.task_serializerjsonpytest test_glossary.py-v# 3 passed4. 项目总结4.1 优点 缺点维度Celery异步任务队列对比线程池 数据库状态表可靠性消息有持久化 确认机制进程崩了任务可重投线程池内任务随进程消失状态表需要自己写补偿横向扩展Worker 是独立进程可随便加机器线程池受限于单进程编排能力Canvas 原生支持 chain/group/chord全手写状态机可观测性Events Flower 信号机制只有应用日志缺点 1引入中间件依赖Broker 高可用要自己扛无额外依赖缺点 2学习曲线陡术语多本章目的心智模型简单缺点 3消息有重复执行的可能必须幂等进程内天然不重4.2 适用场景适用① 下单后发短信/邮件/推送等通知类任务② 库存扣减、发票生成等非即时必达的写操作③ 大促削峰任务排队消费端限速④ 定时对账/报表配合 Beat⑤ 跨系统解耦订单系统不直接依赖短信网关。不适用① 强实时交互如在线支付同步确认必须拿到网关结果才返回② 任务执行与结果强依赖同一个数据库事务的场景需配合 Outbox 模式第 27 章讲③ 极端高频低延迟单任务微秒级直接用 RPC 更合适。4.3 注意事项生产禁用 pickle 序列化任意代码执行风险默认 JSON 是安全的起点第 12 章细讲。默认所有任务挤在celery一条队列里邮件、报表、支付回调会互相饿死第 9 章解决。Broker 与 Backend 是两个不同的东西别只配一个 Redis 就以为万事大吉——Backend 结果还有过期时间问题第 8 章。4.4 常见踩坑经验3 个生产故障故障下单接口偶发 5 秒超时。根因短信、库存、审计三个同步调用串行内联在 HTTP 请求里第三方网关一次 3s 慢响应直接拖垮链路。对策全部改为异步任务投递接口 P99 回到 80ms。教训接口里只做「必须同步」的事。故障大促当天短信网关被打挂短信大面积丢失。根因没有队列缓冲10 倍流量同步直连三方。对策引入 Celery Broker 排队消费端限速 200 条/秒。教训削峰的前提是先把流量「存起来」。故障订单发了两条短信用户投诉。根因任务在 Worker 崩溃后重投而短信发送逻辑没做幂等。对策短信任务以 order_id 为幂等键去重第 11 章。教训异步任务默认可能会被重复执行幂等不是可选项。4.5 思考题为什么说「Celery 不是线程池包装器而是分布式 Actor 消息中间件」请从「任务消息的持久化位置」和「执行者与生产者的进程隔离」两个角度回答。如果 Broker 和 Backend 都用 Redis任务刚发出去时 Broker 挂了任务会丢吗如果 Worker 在acks_lateFalse时收到消息后立刻崩溃呢提示先区分「消息是否已确认」再回答答案见第 2 章的「上一章思考题参考答案」。延伸阅读与资源Java 工程师进阶从 JVM 生产排障到OpenJDK原理NumPy 从入门到生产落地全链路实战指南科学计算/向量化Redis 8 实战精讲从 CRUD 到源码构建高可用缓存系统Redis 实战修炼与原理进阶Python 3实战精进从脚本到高并发订单引擎python入门Rquests从菜鸟脚本到企业级SDK的网络实战圣经Milvus向量数据库实战修炼从 0 到 1精通向量检索与生产落地MongoDB 实战进阶与内核修炼后端工程师的 AI 转型第一课Ollama 与私有化大模型实战10倍开发者的 Dify 魔法书从零构建全栈 AI 应用后端工程师转型AI第一课-Ollama 与私有化大模型实战大型语言模型(LLM) vLLM 高性能推理落地实战Agent开发之LlamaIndex 实战修炼与源码进阶大语言模型Transformers 实战修炼与源码剖析