Celery 的底层架构正是把进程池、事件循环、epoll 和协程全部组合在了一起。 它本质上是一个分布式任务队列，核心架构由 Producer（生产者）、Broker（消息中间件）、Worker（消费者）和 Result Backend（结果存储）四个角色组成。
📌 任务派发与执行流程
- Producer 提交任务 ：应用调用
task.delay()，Celery 将"任务名 + 参数"序列化后推送到 Broker（如 Redis/RabbitMQ） - Worker 拉取任务：Worker 订阅 Broker 队列，通过 epoll 事件驱动监听新消息，拿到任务后反序列化为 Python 函数调用
- 分发到并发池执行：Worker 内部维护一个并发池，将任务分发给池中的进程/协程执行
- 结果存储：执行结果写入 Result Backend，客户端可随时查询状态
📌 核心机制：prefork 预生成进程池
Celery 默认使用 prefork（预生成） 模式，这正是之前聊的进程池：
- Worker 启动时，主进程（Master）提前 fork 出一批子进程（Slave）组成进程池
- 子进程平时休眠，主进程派发任务时唤醒其中一个，通过管道传递任务数据
- 这就是"提前创建好进程反复复用"，避免频繁创建销毁的开销
📌 底层调度：epoll 事件驱动
Master 调度器基于 epoll 事件驱动模型，通过 epoll 同时监听 Broker 消息、子进程状态、控制命令等多个 IO 事件，事件就绪后触发回调，消灭了阻塞。
📌 多种并发模型选择
Celery 支持 4 种并发引擎（--pool 参数），对应之前学的不同并发方式：
| 并发引擎 | 底层机制 | 适用场景 |
|---|---|---|
| prefork（默认） | 多进程（multiprocessing） | CPU 密集型 |
| eventlet | 协程（green threads） | I/O 密集型 |
| gevent | 协程（libev 事件循环） | I/O 密集型 |
| solo | 单进程同步执行 | 调试/测试 |
📌 串联知识体系
Celery 完美印证了之前学的概念：
- 进程池 = Celery 的 prefork 模式（提前创建进程复用）
- 事件循环 + epoll = Celery Master 调度器的底层机制
- 协程 = eventlet/gevent 模式（I/O 密集型用协程）
- 多进程 vs 多线程 = Celery 默认多进程（CPU 密集），也可切协程（I/O 密集）
- 分布式 = 多个 Worker 部署在不同机器上，通过 Broker 协调，实现横向扩展
一句话总结：Celery = 消息队列（Broker）+ 进程池（prefork）+ 事件驱动（epoll）+ 多种并发模型。它就是把之前学的进程池、事件循环、epoll 这些底层概念，包装成了一个开箱即用的分布式任务调度框架。