Celery是一个专注于实时处理和任务调度的分布式任务队列。所谓任务就是消息,消息中的有效载荷中包含要执行任务需要的全部数据。
使用Celery的常见场景如下:
1. Web应用。当用户触发的一个操作需要较长时间才能执行完成时,可以把它作为任务交给Celery去异步执行,执行完再返回给用户。这段时间用户不需要等待,提高了网站的整体吞吐量和响应时间。
2. 定时任务。生产环境经常会跑一些定时任务。假如你有上千台的服务器、上千种任务,定时任务的管理很困难,Celery可以帮助我们快速在不同的机器设定不同种任务。
3. 同步完成的附加工作都可以异步完成。比如发送短信/邮件、推送消息、清理/设置缓存等。
Celery还提供了如下的特性:
1. 方便地查看定时任务的执行情况,比如执行是否成功、当前状态、执行任务花费的时间等。
2. 可以使用功能齐备的管理后台或者命令行添加、更新、删除任务。
3. 方便把任务和配置管理相关联。
4. 可选多进程、Eventlet和Gevent三种模式并发执行。
5. 提供错误处理机制。
- 提供多种任务原语,方便实现任务分组、拆分和调用链。
- 支持多种消息代理和存储后端。
Celery的架构
Celery包含如下组件:
1. Celery Beat:任务调度器,Beat进程会读取配置文件的内容,周期性地将配置中到期需要执行的任务发送给任务队列。
2. Celery Worker:执行任务的消费者,通常会在多台服务器运行多个消费者来提高执行效率。
3. Broker:消息代理,或者叫作消息中间件,接受任务生产者发送过来的任务消息,存进队列再按序分发给任务消费方(通常是消息队列或者数据库)。
4. Producer:调用了Celery提供的API、函数或者装饰器而产生任务并交给任务队列处理的都是任务生产者。
5. Result Backend:任务处理完后保存状态信息和结果,以供查询。Celery默认已支持Redis、RabbitMQ、MongoDB、Django ORM、SQLAlchemy等方式。
Celery的架构图如图所示:

选择消息代理
Celery目前支持RabbitMQ、Redis、MongoDB、Beanstalk、SQLAlchemy、Zookeeper等作为消息代理,但适用于生产环境的只有RabbitMQ和Redis,至于其他的方式,一是支持有限,二是可能得不到更好的技术支持。
Celery官方推荐的是RabbitMQ,Celery的作者Ask Solem Hoel最初在VMware就是为RabbitMQ工作的,Celery最初的设计就是基于RabbitMQ,所以使用RabbitMQ会非常稳定,成功案例很多。如果使用Redis,则需要能接受发生突然断电之类的问题造成Redis突然终止后的数据丢失等后果。
Celery序列化
在客户端和消费者之间传输数据需要序列化和反序列化,Celery支持如表9.2所示的序列化方案:

1. 选择RabbitMQ作为消息代理。
2. RabbitMQ的Python客户端选择librabbitmq这个C库。
3. 选择Msgpack做序列化。
4. 选择Redis做结果存储。
下面先安装它们。Celery提供bundles的方式,也就是安装Celery的同时可以一起安装多种依赖:
❯ pip install "celery[librabbitmq,redis,msgpack]"
注:bundles的原理是在setup.py的setup函数中添加extras_require。
从一个简单的例子开始
先演示一个简单的项目让Celery运行起来。项目的目录结构如下:
❯ tree chapter9/section3/proj
├── celeryconfig.py
├── celery.py
├── __init__.py
└── tasks.py
先看一下主程序celery.py:
from __future__ import absolute_import
from celery import Celery
app = Celery('proj', include=['proj.tasks'])
app.config_from_object('proj.celeryconfig')
if __name__ == '__main__':
app.start()
解析一下这个程序:
1. "from __future__ import absolute_import"是拒绝隐式引入,因为celery.py的名字和celery的包名冲突,需要使用这条语句让程序正确地运行。
2. app是Celery类的实例,创建的时候添加了proj.tasks这个模块,也就是包含了proj/tasks.py这个文件。
3. 把Celery配置存放进proj/celeryconfig.py文件,使用app.config_from_object加载配置。
看一下存放任务函数的文件tasks.py:
from __future__ import absolute_import
from proj.celery import app
@app.task
def add(x, y):
return x + y
tasks.py只有一个任务函数add,让它生效的最直接的方法就是添加app.task这个装饰器。
看一下我们的配置文件celeryconfig.py:
BROKER_URL = 'amqp://dongwm:123456@localhost:5672/web_develop' # 使用RabbitMQ作为消息代理
CELERY_RESULT_BACKEND = 'redis://localhost:6379/0' # 把任务结果存在了Redis
CELERY_TASK_SERIALIZER = 'msgpack' # 任务序列化和反序列化使用msgpack方案
CELERY_RESULT_SERIALIZER = 'json' # 读取任务结果一般性能要求不高,所以使用了可读性更好的JSON
CELERY_TASK_RESULT_EXPIRES = 60 * 60 * 24 # 任务过期时间,不建议直接写86400,应该让这样的magic数字表述更明显
CELERY_ACCEPT_CONTENT = ['json', 'msgpack'] # 指定接受的内容类型
这个例子中没有任务调度相关的内容, 所以只需要启动消费者:
❯ cd ~/web_develop/chapter9/section3
❯ celery -A proj worker -l info
-A参数默认会寻找proj.celery这个模块,其实使用celery作为模块文件名字不怎么合理。可以使用其他名字。举个例子,假如是proj/app.py,可以使用如下命令启动:
❯ celery -A proj.app worker -l info
如果看到l如下的启动信息,就说明worker服务运行起来了:
--- * *** * -- Linux-4.4.0-22-generic-x86_64-with-Ubuntu-16.04-xenial
-- * - **** ---
- ** ---------- [config]
- ** ---------- .> app: proj:0x7f444c1b01d0
- ** ---------- .> transport: amqp://dongwm:**&#