第19章：Celery 分布式任务队列深度解析

1. 项目背景

"我上传了一份 200 页的 PDF 到知识库，点击’保存并处理’后页面显示索引进度 0%。等了 30 分钟终于跳到 100%，中间我刷新了 5 次页面，每次都以为卡死了。"这是新手使用 Dify 知识库最常见的困惑。30 分钟里，Dify 的后台 Celery Worker 一直在拼命工作：提取 PDF 文本、切成 800 段、调用 Embedding API 生成 800 条 1536 维向量、逐条写入 Weaviate 向量数据库。

如果把这个过程放在 HTTP 请求里同步处理——让用户在浏览器前干等 30 分钟——那运维早就被投诉淹没了。Dify 使用 Celery（Python 生态最成熟的分布式任务队列）来处理所有耗时操作。但 Celery 不是简单的"扔到后台就不管了"——你需要理解三个核心问题：

1. 任务是如何从 API 进程到 Worker 进程的？（Producer → Broker → Consumer 模式）
2. 多租户的任务如何隔离？（租户独占队列tenant_self_*_task_queue）
3. Flask 请求上下文如何在 Worker 中可用？（FlaskTask 包装器）

理解这三个问题，你才能排查"知识库索引卡住"“Workflow 异步执行超时”"定时任务没有触发"等生产故障。

2. 项目设计

小胖：（指着 Dify 控制台