0. 上一章思考题参考答案思考题 1按 CPU 扩缩看的是「计算资源利用率」——而任务系统多是等待型第 17 章CPU 只有 5%永远触发不了扩容按队列积压扩缩看的是「工作堆积量」直接对应「任务系统的心跳」——积压高就加人加 Pod、积压消化就缩人这才是任务系统的真实负载信号。所以 HPA 指标选型任务系统用积压业务语义Web 系统用 CPU/QPS资源语义。思考题 2三级回滚里最容易踩的是「消息格式不兼容」回滚到旧版本 Worker但队列里还躺着新格式的消息参数增删——旧 Worker 消费即错。解法版本字段消息带schema_version旧 Worker 兼容跳过/降级处理 第 6 章契约演进新参数带默认值、语义变化开 v2 任务名 回滚配合「消息 TTL 过期」让不兼容消息自然消亡第 21 章。1. 项目背景从中级篇进入高级篇第一站是源码。触发点是一次真实事故大促发布时运维在SIGTERM后立刻观察 Worker发现「信号发出后Worker 竟然又跑了好一会儿」——有人以为是 bug 要紧急 kill有人说是优雅退出双方僵持 20 分钟。大师说「谁把celery/apps/worker.py的启动链路读一遍答案自然出来。」小周读源码时又发现了更多「为什么」celery -A启动 Worker 后日志里Connected to redis→mingle: searching for neighbors→ready.的顺序是谁决定的第 2 章的自定义 Bootstep 插件机制靠的又是什么数据结构带着三个问题小周打开celery/bootsteps.py——原来 Worker 的启动不是「顺序执行的一串代码」而是一个「有向图」Worker 组件celery/worker/components.py Timer(32) → Hub(56) → Pool(101) → Beat(181) → Consumer(221) 依赖关系Consumer 依赖前面全部Pool 依赖 HubHub 依赖 Timer阅读方法提示本章与第 33 章是高级篇「源码双章」建议对照本仓库源码逐行阅读而不是只看本章代码块——源码阅读的正确姿势是「带着问题读」本章的每个结论都对应源码里的一行注释或一个方法名读完试着不看本章自己把依赖图默画一遍能画出来才算真读懂。本章目标读懂bootsteps的有向图机制画出 Worker 完整 Bootstep 依赖图并编写一个自定义 Step打印「池大小与订阅队列」——从源码读者变成源码使用者。2. 项目设计场景小周把「SIGTERM 后还跑了一会儿」的日志贴在白板上大师开讲。小胖我不是杠啊——信号都发了进程还赖着不走这不是 bug 是什么重启大法不香吗非要研究什么启动链路小白小胖你这就是「重启解决一切」的典型——第 15 章就批过。我先问技术问题celery/bootsteps.py里的Step、StartStopStep、ConsumerStep有什么区别我看了下WorkControllercelery/worker/worker.py:63把一堆 step 塞进Blueprint这个 Blueprint 是啥大师先回答结构。Blueprint是「步骤编排器」它把 step 们按依赖关系排成有向无环图DAG然后按拓扑序执行start、反向执行stop。三种 Step 的区别类基类特点典型成员Stepbootsteps.py:288—只有__init__/include无生命周期Timer组件StartStopStep:355Step有start/stop钩子Hub、Pool、Beat、ConsumerConsumerStep:386StartStopStep专为「消费通道」设计get_consumers()返回消费者列表Gossip、Agent第 33 章Worker 的组件依赖celery/worker/components.pyTimer定时器负责 ETA 任务→Hub事件循环evloop的底座→Pool并发池第 17 章→Beat嵌入式调度可选→Consumer消费管线第 33 章——Consumer 是最后启动的因为它依赖前面所有组件第 33 章接着读它。技术映射Blueprint 飞机的「起飞检查单」——发动机Timer、液压Hub、引擎推力Pool、导航Consumer按依赖顺序启动关机时逆序进行检查单的顺序就是「有向图」不是拍脑袋排的。小白那「SIGTERM 后还跑一会儿」的答案就在这个逆序里Worker 的关闭流程到底是什么大师正是。关闭 启动的逆序SIGTERM→ Worker 进入shutdown→ Blueprint 逆拓扑序执行各 Step 的stop——Consumer 先停停止接新消息然后 Pool 优雅退出在途任务执行完受worker_shutdown_timeout限制第 29 章最后 Hub/Timer 收尾。所以「信号后还跑一会儿」在途任务在跑完是优雅退出设计的正解不是 bug。反过来想如果 Pool 没等任务跑完就杀早确认的消息就丢了第 18 章——启动顺序的正确性直接决定关闭时会不会丢任务。小胖那我能不能给 Worker 加个自定义组件比如打印「池大小和订阅队列」听起来像给飞机加个「仪表盘」大师完全可以而且这是高级篇第一个「动手改框架」的练习。自定义 Step 的写法继承StartStopStep实现start()然后通过worker.user_options或Worker.add把它注册进 Blueprint。框架把 Step 的生命周期钩子留好了start/stop/shutdown你只管在钩子里写自己的逻辑——这就是「插件化架构」Worker 的一节节「开机」每一节都可以被替换或插入第 33 章 Consumer 管线、第 38 章自定义扩展都基于它。技术映射自定义 Step 给飞机驾驶舱加一块「自定义仪表」——不需要重造飞机只需要在检查单Blueprint的某个位置「插一块表」起飞时它会跟着点亮start、落地时跟着熄灭stop。3. 项目实战3.1 环境准备沿用环境Redis Broker。本章全部在源码层面操作可编辑安装第 2 章环境。# 确认源码可编辑安装改动立即生效python-cimport celery, os; print(os.path.dirname(celery.__file__))# 应输出仓库路径 ...\celery-main\celery3.2 分步实现步骤 1画出 Worker 的 Bootstep 依赖图目标把源码里的类关系变成一张图沉淀 Wiki 的第一份源码资产。WorkControllercelery/worker/worker.py:63 └── Blueprintcelery/bootsteps.py ├── Timer (components.py:32, Step) # ETA 定时器 ├── Hub (components.py:56, StartStopStep) # 事件循环 │ └── 依赖 Timer ├── Pool (components.py:101, StartStopStep) # 并发池 │ └── 依赖 Hub结果处理器挂在 Hub 上 ├── Beat (components.py:181, StartStopStep) # 嵌入式调度可选 ├── Consumer (components.py:221, StartStopStep) # 消费管线第 33 章 │ └── 依赖 Timer/Hub/Pool/Beat 全部 └──启动时按拓扑序 startSIGTERM 后逆序 stop步骤 2用日志实证启动与关闭顺序目标观察真实启动日志与依赖图对照。celery-Aorder_tasks worker--logleveldebug--poolsolo-Qsms21|Select-StringLoading|start|mingle|ready|Starting运行结果文字描述节选[DEBUG] Loading modules... # Step 类加载 [INFO] mingle: searching for neighbors # Consumer 管线第 33 章 [INFO] celeryDESKTOP ready. # 全部 start 完成 # 按 CtrlCSIGTERM [INFO] Warm shutdown (MainProcess) # 逆序 stop 开始 [INFO] mingle: leaving # 在途任务跑完后退出对照依赖图ready.前是 Consumer 的 Mingle第 33 章Warm shutdown后 Worker 还在把在途任务跑完——这就是第 1 节事故的答案。步骤 3编写自定义 Step——打印「池大小与订阅队列」目标从「读源码」到「写插件」掌握 Step 生命周期钩子。# custom_step.pyfromcelery.bootstepsimportStartStopStepfromcelery.utils.logimportget_task_logger loggerget_task_logger(__name__)classPrintInfoStep(StartStopStep):自定义仪表盘启动时打印池大小与订阅队列。requires(celery.worker.components.Pool,)# 依赖 Pool 先启动defstart(self,parent):poolparent.pool# 并发池实例第 17 章concurrencygetattr(pool,concurrency,unknown)queuesgetattr(parent,app,None)logger.info( 自定义 Step: 池大小%s,concurrency)# 订阅队列从 Consumer 侧取第 33 章 Tasks step 的队列集合try:qnameslist(parent.consumer.task_consumer.queues)if\ parent.consumerelseconsumer-not-readylogger.info( 自定义 Step: 订阅队列%s,qnames)exceptExceptionasexc:logger.info( 自定义 Step: 队列信息不可用: %s,exc)# 挂载方式一通过 -A 模块的 user_options 或直接 add演示用最简方式# 在 Worker 启动模块里注册fromorder_tasksimportappfromcustom_stepimportPrintInfoStepapp.on_after_configure.connectdefinstall_custom_step(sender,**kwargs):sender.steps[worker].add(PrintInfoStep)# 注册进 Worker Blueprintcelery-Aorder_tasks worker--loglevelinfo--poolsolo-Qsms运行结果文字描述[INFO] 自定义 Step: 池大小1 # solo 池 [INFO] 自定义 Step: 订阅队列... sms ... # -Q sms 生效 [INFO] celeryDESKTOP ready.验证插件的「仪表盘」性质把-Q sms换成-Q order、-c 4重新启动自定义 Step 的输出跟着变化——Step 在每次启动时重新读取运行状态这就是插件化架构的威力不改框架只插仪表。步骤 4理解requires与依赖解析目标验证「requires 决定启动顺序」——故意声明错误依赖观察报错。# 反例演示声明一个不存在的依赖classBadStep(StartStopStep):requires(celery.worker.components.Nope,)# 启动报错AttributeError / KeyError —— 依赖不满足Blueprint 拒绝装配运行结果文字描述Worker 启动时 Blueprint 尝试解析Nope失败直接报错退出——依赖图不是「建议」而是「契约」requires 声明错了Worker 根本起不来。这解释了为什么框架对启动顺序如此谨慎顺序错了丢任务依赖错了起不来。步骤 5观察关闭顺序——在自定义 Step 里打印 stop 时机目标验证「关闭 启动逆序」的源码结论亲手回答第 1 节的事故。# custom_step.py 追加 stop 钩子classPrintInfoStep(StartStopStep):defstop(self,parent):logger.info( 自定义 Step stop: 进入关闭阶段)celery-Aorder_tasks worker--loglevelinfo--poolsolo-Qsms# 按 CtrlCSIGTERM观察日志顺序运行结果文字描述^C [INFO] 自定义 Step stop: 进入关闭阶段 # 自定义 Step 先停 [INFO] Warm shutdown (MainProcess) # 框架进入温暖关闭 [INFO] mingle: leaving # 在途任务跑完注意顺序自定义 Step 的 stop 在「Warm shutdown」之前触发——因为关闭是逆拓扑序后注册的 Step 先停。这就是「SIGTERM 后还跑一会儿」的完整源码答案停止接单各 Step stop→ 在途任务跑完Pool 优雅退出→ 进程退出。3.3 可能遇到的坑及解决方法坑现象解决自定义 Step 不执行requires 写错/没注册用sender.steps[worker].add()注册requires 指向真实组件start 里访问 parent.consumer时序不对Consumer 还没起用requires声明依赖或parent.on_consumer_ready回调SIGTERM 后立刻退出以为「赖着不走」是 bug 强制 kill那是优雅退出在跑在途任务第 29 章给足宽限期Step 改了不生效没重启 WorkerStep 在启动时装配改动必须重启3.4 完整代码清单与测试验证清单custom_step.py 注册代码 启动命令。源码阅读路线本章对应celery/bootsteps.py、celery/worker/components.py、celery/worker/worker.py、celery/apps/worker.py。测试验证# tests/test_bootsteps.pyfromcustom_stepimportPrintInfoStepdeftest_step_is_startstopstep():fromcelery.bootstepsimportStartStopStepassertissubclass(PrintInfoStep,StartStopStep)deftest_step_requires_pool():assertcelery.worker.components.PoolinPrintInfoStep.requiresdeftest_worker_components_exist():# 组件类真实存在于源码对照依赖图importcelery.worker.componentsascfornamein(Timer,Hub,Pool,Beat,Consumer):asserthasattr(c,name)python-mpytest tests/test_bootsteps.py-v# 3 passed4. 项目总结4.1 优点 缺点维度Bootstep 插件化架构顺序硬编码启动扩展性任意插入自定义 Step改框架代码顺序保障依赖图自动拓扑排序人肉维护顺序关闭安全逆序停止、在途任务跑完顺序即错即丢学习成本需要理解 DAG 概念直观调试依赖错误直接报错运行时才暴露4.2 适用场景适用① 需要 Worker 启动钩子注册中心上下线、指标初始化② 需要消费通道扩展第 33/38 章③ 理解框架「为什么这样启动」的排障SIGTERM 行为、启动时序④ 框架升级前的启动兼容性回归。不适用① 业务任务逻辑任务不需要 Step走 Task 体系② 简单环境变量注入配置系统够用③ 需要「运行期热插拔」的逻辑Step 是启动期装配。4.3 注意事项requires是依赖契约写错 Worker 起不来写少不声明可能拿到「未初始化的组件」。Step 的start里不要做重活它发生在启动主路径卡住 Worker 起不来——初始化放__init__周期性任务放 Timer。关闭顺序是启动逆序在stop里做清理关连接、摘流别在start里「只开不关」。修改框架源码可编辑安装后要回滚干净用 git 或注释标记别把实验代码留在生产环境。第 32/33 章是「读源码」的入门双章本章看「开机」第 33 章看「消费」——两张依赖图合起来就是 Worker 的完整骨架。4.4 常见踩坑经验3 个生产故障故障升级 Celery 后 Worker 启动顺序变了自定义监控 Step 拿不到数据。根因新版组件名/时序变化requires 失效。对策升级后跑一遍依赖图对照 启动日志对比。教训插件架构的兼容性靠「依赖契约」兜底升级要回归。故障SIGTERM 后 5 分钟进程不退出被 K8s SIGKILL。根因在途长任务 worker_shutdown_timeout未配宽限被 SIGKILL 截断第 29 章。对策配超时 长任务拆短。教训优雅退出的「优雅」是配置出来的。故障自定义 Step 里写了同步 HTTP 调用Worker 启动慢 30 秒。根因重活放在了 start 主路径。对策移到worker_ready信号第 26 章或异步初始化。教训启动路径上的每毫秒都是全集群的启动成本。故障扩容 10 个 WorkerRedis 连接数瞬间翻倍引发告警。根因每个 Worker 的 Connection/Hub/Pool 各自建连扩容是「乘法」不是「加法」。对策连接数 副本数 × 每副本连接数第 30 章容量公式加一列限流 Broker 侧 maxclients。教训扩容的账单在连接层不在 Pod 数。4.5 思考题ConsumerStep的get_consumers()返回什么它和StartStopStep的start()在执行时机上有什么不同提示第 33 章 Gossip 是 ConsumerStep 的例子Worker 的Hub事件循环为什么要先于Pool启动如果顺序反过来会怎样提示结果回传、信号处理的依赖答案见第 33 章开头的「上一章思考题参考答案」。本章的依赖图与第 33 章消费管线图是高级篇源码阅读的两张「总地图」——先有图再入山。延伸阅读与资源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 实战修炼与源码剖析 第32章：Celery Bootsteps 与 Worker 启动链路源码
0. 上一章思考题参考答案思考题 1按 CPU 扩缩看的是「计算资源利用率」——而任务系统多是等待型第 17 章CPU 只有 5%永远触发不了扩容按队列积压扩缩看的是「工作堆积量」直接对应「任务系统的心跳」——积压高就加人加 Pod、积压消化就缩人这才是任务系统的真实负载信号。所以 HPA 指标选型任务系统用积压业务语义Web 系统用 CPU/QPS资源语义。思考题 2三级回滚里最容易踩的是「消息格式不兼容」回滚到旧版本 Worker但队列里还躺着新格式的消息参数增删——旧 Worker 消费即错。解法版本字段消息带schema_version旧 Worker 兼容跳过/降级处理 第 6 章契约演进新参数带默认值、语义变化开 v2 任务名 回滚配合「消息 TTL 过期」让不兼容消息自然消亡第 21 章。1. 项目背景从中级篇进入高级篇第一站是源码。触发点是一次真实事故大促发布时运维在SIGTERM后立刻观察 Worker发现「信号发出后Worker 竟然又跑了好一会儿」——有人以为是 bug 要紧急 kill有人说是优雅退出双方僵持 20 分钟。大师说「谁把celery/apps/worker.py的启动链路读一遍答案自然出来。」小周读源码时又发现了更多「为什么」celery -A启动 Worker 后日志里Connected to redis→mingle: searching for neighbors→ready.的顺序是谁决定的第 2 章的自定义 Bootstep 插件机制靠的又是什么数据结构带着三个问题小周打开celery/bootsteps.py——原来 Worker 的启动不是「顺序执行的一串代码」而是一个「有向图」Worker 组件celery/worker/components.py Timer(32) → Hub(56) → Pool(101) → Beat(181) → Consumer(221) 依赖关系Consumer 依赖前面全部Pool 依赖 HubHub 依赖 Timer阅读方法提示本章与第 33 章是高级篇「源码双章」建议对照本仓库源码逐行阅读而不是只看本章代码块——源码阅读的正确姿势是「带着问题读」本章的每个结论都对应源码里的一行注释或一个方法名读完试着不看本章自己把依赖图默画一遍能画出来才算真读懂。本章目标读懂bootsteps的有向图机制画出 Worker 完整 Bootstep 依赖图并编写一个自定义 Step打印「池大小与订阅队列」——从源码读者变成源码使用者。2. 项目设计场景小周把「SIGTERM 后还跑了一会儿」的日志贴在白板上大师开讲。小胖我不是杠啊——信号都发了进程还赖着不走这不是 bug 是什么重启大法不香吗非要研究什么启动链路小白小胖你这就是「重启解决一切」的典型——第 15 章就批过。我先问技术问题celery/bootsteps.py里的Step、StartStopStep、ConsumerStep有什么区别我看了下WorkControllercelery/worker/worker.py:63把一堆 step 塞进Blueprint这个 Blueprint 是啥大师先回答结构。Blueprint是「步骤编排器」它把 step 们按依赖关系排成有向无环图DAG然后按拓扑序执行start、反向执行stop。三种 Step 的区别类基类特点典型成员Stepbootsteps.py:288—只有__init__/include无生命周期Timer组件StartStopStep:355Step有start/stop钩子Hub、Pool、Beat、ConsumerConsumerStep:386StartStopStep专为「消费通道」设计get_consumers()返回消费者列表Gossip、Agent第 33 章Worker 的组件依赖celery/worker/components.pyTimer定时器负责 ETA 任务→Hub事件循环evloop的底座→Pool并发池第 17 章→Beat嵌入式调度可选→Consumer消费管线第 33 章——Consumer 是最后启动的因为它依赖前面所有组件第 33 章接着读它。技术映射Blueprint 飞机的「起飞检查单」——发动机Timer、液压Hub、引擎推力Pool、导航Consumer按依赖顺序启动关机时逆序进行检查单的顺序就是「有向图」不是拍脑袋排的。小白那「SIGTERM 后还跑一会儿」的答案就在这个逆序里Worker 的关闭流程到底是什么大师正是。关闭 启动的逆序SIGTERM→ Worker 进入shutdown→ Blueprint 逆拓扑序执行各 Step 的stop——Consumer 先停停止接新消息然后 Pool 优雅退出在途任务执行完受worker_shutdown_timeout限制第 29 章最后 Hub/Timer 收尾。所以「信号后还跑一会儿」在途任务在跑完是优雅退出设计的正解不是 bug。反过来想如果 Pool 没等任务跑完就杀早确认的消息就丢了第 18 章——启动顺序的正确性直接决定关闭时会不会丢任务。小胖那我能不能给 Worker 加个自定义组件比如打印「池大小和订阅队列」听起来像给飞机加个「仪表盘」大师完全可以而且这是高级篇第一个「动手改框架」的练习。自定义 Step 的写法继承StartStopStep实现start()然后通过worker.user_options或Worker.add把它注册进 Blueprint。框架把 Step 的生命周期钩子留好了start/stop/shutdown你只管在钩子里写自己的逻辑——这就是「插件化架构」Worker 的一节节「开机」每一节都可以被替换或插入第 33 章 Consumer 管线、第 38 章自定义扩展都基于它。技术映射自定义 Step 给飞机驾驶舱加一块「自定义仪表」——不需要重造飞机只需要在检查单Blueprint的某个位置「插一块表」起飞时它会跟着点亮start、落地时跟着熄灭stop。3. 项目实战3.1 环境准备沿用环境Redis Broker。本章全部在源码层面操作可编辑安装第 2 章环境。# 确认源码可编辑安装改动立即生效python-cimport celery, os; print(os.path.dirname(celery.__file__))# 应输出仓库路径 ...\celery-main\celery3.2 分步实现步骤 1画出 Worker 的 Bootstep 依赖图目标把源码里的类关系变成一张图沉淀 Wiki 的第一份源码资产。WorkControllercelery/worker/worker.py:63 └── Blueprintcelery/bootsteps.py ├── Timer (components.py:32, Step) # ETA 定时器 ├── Hub (components.py:56, StartStopStep) # 事件循环 │ └── 依赖 Timer ├── Pool (components.py:101, StartStopStep) # 并发池 │ └── 依赖 Hub结果处理器挂在 Hub 上 ├── Beat (components.py:181, StartStopStep) # 嵌入式调度可选 ├── Consumer (components.py:221, StartStopStep) # 消费管线第 33 章 │ └── 依赖 Timer/Hub/Pool/Beat 全部 └──启动时按拓扑序 startSIGTERM 后逆序 stop步骤 2用日志实证启动与关闭顺序目标观察真实启动日志与依赖图对照。celery-Aorder_tasks worker--logleveldebug--poolsolo-Qsms21|Select-StringLoading|start|mingle|ready|Starting运行结果文字描述节选[DEBUG] Loading modules... # Step 类加载 [INFO] mingle: searching for neighbors # Consumer 管线第 33 章 [INFO] celeryDESKTOP ready. # 全部 start 完成 # 按 CtrlCSIGTERM [INFO] Warm shutdown (MainProcess) # 逆序 stop 开始 [INFO] mingle: leaving # 在途任务跑完后退出对照依赖图ready.前是 Consumer 的 Mingle第 33 章Warm shutdown后 Worker 还在把在途任务跑完——这就是第 1 节事故的答案。步骤 3编写自定义 Step——打印「池大小与订阅队列」目标从「读源码」到「写插件」掌握 Step 生命周期钩子。# custom_step.pyfromcelery.bootstepsimportStartStopStepfromcelery.utils.logimportget_task_logger loggerget_task_logger(__name__)classPrintInfoStep(StartStopStep):自定义仪表盘启动时打印池大小与订阅队列。requires(celery.worker.components.Pool,)# 依赖 Pool 先启动defstart(self,parent):poolparent.pool# 并发池实例第 17 章concurrencygetattr(pool,concurrency,unknown)queuesgetattr(parent,app,None)logger.info( 自定义 Step: 池大小%s,concurrency)# 订阅队列从 Consumer 侧取第 33 章 Tasks step 的队列集合try:qnameslist(parent.consumer.task_consumer.queues)if\ parent.consumerelseconsumer-not-readylogger.info( 自定义 Step: 订阅队列%s,qnames)exceptExceptionasexc:logger.info( 自定义 Step: 队列信息不可用: %s,exc)# 挂载方式一通过 -A 模块的 user_options 或直接 add演示用最简方式# 在 Worker 启动模块里注册fromorder_tasksimportappfromcustom_stepimportPrintInfoStepapp.on_after_configure.connectdefinstall_custom_step(sender,**kwargs):sender.steps[worker].add(PrintInfoStep)# 注册进 Worker Blueprintcelery-Aorder_tasks worker--loglevelinfo--poolsolo-Qsms运行结果文字描述[INFO] 自定义 Step: 池大小1 # solo 池 [INFO] 自定义 Step: 订阅队列... sms ... # -Q sms 生效 [INFO] celeryDESKTOP ready.验证插件的「仪表盘」性质把-Q sms换成-Q order、-c 4重新启动自定义 Step 的输出跟着变化——Step 在每次启动时重新读取运行状态这就是插件化架构的威力不改框架只插仪表。步骤 4理解requires与依赖解析目标验证「requires 决定启动顺序」——故意声明错误依赖观察报错。# 反例演示声明一个不存在的依赖classBadStep(StartStopStep):requires(celery.worker.components.Nope,)# 启动报错AttributeError / KeyError —— 依赖不满足Blueprint 拒绝装配运行结果文字描述Worker 启动时 Blueprint 尝试解析Nope失败直接报错退出——依赖图不是「建议」而是「契约」requires 声明错了Worker 根本起不来。这解释了为什么框架对启动顺序如此谨慎顺序错了丢任务依赖错了起不来。步骤 5观察关闭顺序——在自定义 Step 里打印 stop 时机目标验证「关闭 启动逆序」的源码结论亲手回答第 1 节的事故。# custom_step.py 追加 stop 钩子classPrintInfoStep(StartStopStep):defstop(self,parent):logger.info( 自定义 Step stop: 进入关闭阶段)celery-Aorder_tasks worker--loglevelinfo--poolsolo-Qsms# 按 CtrlCSIGTERM观察日志顺序运行结果文字描述^C [INFO] 自定义 Step stop: 进入关闭阶段 # 自定义 Step 先停 [INFO] Warm shutdown (MainProcess) # 框架进入温暖关闭 [INFO] mingle: leaving # 在途任务跑完注意顺序自定义 Step 的 stop 在「Warm shutdown」之前触发——因为关闭是逆拓扑序后注册的 Step 先停。这就是「SIGTERM 后还跑一会儿」的完整源码答案停止接单各 Step stop→ 在途任务跑完Pool 优雅退出→ 进程退出。3.3 可能遇到的坑及解决方法坑现象解决自定义 Step 不执行requires 写错/没注册用sender.steps[worker].add()注册requires 指向真实组件start 里访问 parent.consumer时序不对Consumer 还没起用requires声明依赖或parent.on_consumer_ready回调SIGTERM 后立刻退出以为「赖着不走」是 bug 强制 kill那是优雅退出在跑在途任务第 29 章给足宽限期Step 改了不生效没重启 WorkerStep 在启动时装配改动必须重启3.4 完整代码清单与测试验证清单custom_step.py 注册代码 启动命令。源码阅读路线本章对应celery/bootsteps.py、celery/worker/components.py、celery/worker/worker.py、celery/apps/worker.py。测试验证# tests/test_bootsteps.pyfromcustom_stepimportPrintInfoStepdeftest_step_is_startstopstep():fromcelery.bootstepsimportStartStopStepassertissubclass(PrintInfoStep,StartStopStep)deftest_step_requires_pool():assertcelery.worker.components.PoolinPrintInfoStep.requiresdeftest_worker_components_exist():# 组件类真实存在于源码对照依赖图importcelery.worker.componentsascfornamein(Timer,Hub,Pool,Beat,Consumer):asserthasattr(c,name)python-mpytest tests/test_bootsteps.py-v# 3 passed4. 项目总结4.1 优点 缺点维度Bootstep 插件化架构顺序硬编码启动扩展性任意插入自定义 Step改框架代码顺序保障依赖图自动拓扑排序人肉维护顺序关闭安全逆序停止、在途任务跑完顺序即错即丢学习成本需要理解 DAG 概念直观调试依赖错误直接报错运行时才暴露4.2 适用场景适用① 需要 Worker 启动钩子注册中心上下线、指标初始化② 需要消费通道扩展第 33/38 章③ 理解框架「为什么这样启动」的排障SIGTERM 行为、启动时序④ 框架升级前的启动兼容性回归。不适用① 业务任务逻辑任务不需要 Step走 Task 体系② 简单环境变量注入配置系统够用③ 需要「运行期热插拔」的逻辑Step 是启动期装配。4.3 注意事项requires是依赖契约写错 Worker 起不来写少不声明可能拿到「未初始化的组件」。Step 的start里不要做重活它发生在启动主路径卡住 Worker 起不来——初始化放__init__周期性任务放 Timer。关闭顺序是启动逆序在stop里做清理关连接、摘流别在start里「只开不关」。修改框架源码可编辑安装后要回滚干净用 git 或注释标记别把实验代码留在生产环境。第 32/33 章是「读源码」的入门双章本章看「开机」第 33 章看「消费」——两张依赖图合起来就是 Worker 的完整骨架。4.4 常见踩坑经验3 个生产故障故障升级 Celery 后 Worker 启动顺序变了自定义监控 Step 拿不到数据。根因新版组件名/时序变化requires 失效。对策升级后跑一遍依赖图对照 启动日志对比。教训插件架构的兼容性靠「依赖契约」兜底升级要回归。故障SIGTERM 后 5 分钟进程不退出被 K8s SIGKILL。根因在途长任务 worker_shutdown_timeout未配宽限被 SIGKILL 截断第 29 章。对策配超时 长任务拆短。教训优雅退出的「优雅」是配置出来的。故障自定义 Step 里写了同步 HTTP 调用Worker 启动慢 30 秒。根因重活放在了 start 主路径。对策移到worker_ready信号第 26 章或异步初始化。教训启动路径上的每毫秒都是全集群的启动成本。故障扩容 10 个 WorkerRedis 连接数瞬间翻倍引发告警。根因每个 Worker 的 Connection/Hub/Pool 各自建连扩容是「乘法」不是「加法」。对策连接数 副本数 × 每副本连接数第 30 章容量公式加一列限流 Broker 侧 maxclients。教训扩容的账单在连接层不在 Pod 数。4.5 思考题ConsumerStep的get_consumers()返回什么它和StartStopStep的start()在执行时机上有什么不同提示第 33 章 Gossip 是 ConsumerStep 的例子Worker 的Hub事件循环为什么要先于Pool启动如果顺序反过来会怎样提示结果回传、信号处理的依赖答案见第 33 章开头的「上一章思考题参考答案」。本章的依赖图与第 33 章消费管线图是高级篇源码阅读的两张「总地图」——先有图再入山。延伸阅读与资源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 实战修炼与源码剖析