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

选择消息代理
Celery目前支持RabbitMQ、Redis、MongoDB、Beanstalk、SQLAlchemy、Zookeeper等作为消息代理,但适用于生产环境的只有RabbitMQ和Redis,至于其他的方式,一是支持有限,二是可能得不到更好的技术支持。
Celery官方推荐的是RabbitMQ,Celery的作者 Ask Solem Hoel 最初在VMware就是为RabbitMQ工作的,Celery最初的设计就是基于RabbitMQ,所以使用RabbitMQ会非常稳定,成功案例很多。如果使用Redis,则需要能接受发生突然断电之类的问题造成Redis突然终止后的数据丢失等后果。
Celery序列化
在客户端和消费者之间传输数据需要序列化和反序列化,Celery支持如下序列化方案。
pickle。 pickle是Python标准库中的一个模块, 支持Python内置的数据结构, 但是它是Python专有协议。 从Celery 3.2开
始将由于安全性等原因拒绝pickle这个方案。json。 JSON支持多种语言, 可用于跨语言方案。
yaml。 YAML的表达能力更强, 支持比JSON多的数据类型, 但是Python客户端的性能不如JSON。
msgpack。 msgpack是一个二进制的类JSON的序列化方案, 但是比JSON的数据结构更小, 更快。
安装配置Celery
为了提供更高的性能,我们选择如下方案:
选择RabbitMQ作为消息代理。
RabbitMQ的Python客户端选择librabbitmq这个C库。
选择Msgpack做序列化。
选择Redis做结果存储。
下面先安装它们。Celery提供bundles的方式,也就是安装Celery的同时可以一起安装多种依赖:
❯ pip install "celery[librabbitmq,redis,msgpack]"
PS: 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_importfrom celery import Celery
app = Celery('proj', include=['proj.tasks'])
app.config_from_object('proj.celeryconfig')
if __name__ == '__main__':
app.start()
解析一下这个程序:
“from future import absolute_import”是拒绝隐式引入,因为celery.py的名字和celery的包名冲突,需要使用这条语句让程序正确地运行。
app是Celery类的实例,创建的时候添加了proj.tasks这个模块,也就是包含了proj/tasks.py这个文件。
把Celery配置存放进proj/celeryconfig.py文件,使用app.config_from_object加载配置。
看一下存放任务函数的文件tasks.py:
from __future__ import absolute_importfrom proj.celery import app@app.taskdef add(x, y): return x + y
tasks.py只有一个任务函数add,让它生效的最直接的方法就是添加app.task这个装饰器。
看一下我们的配置文件celeryconfig.py:
BROKER_URL = 'amqp://dongwm:123456@localhost:5672/web_develop' CELERY_RESULT_BACKEND = 'redis://localhost:6379/0' CELERY_TASK_SERIALIZER = 'msgpack' CELERY_RESULT_SERIALIZER = 'json' CELERY_TASK_RESULT_EXPIRES = 60 * 60 * 24 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
这样worker就运行起来了。需要注意启动信息中提供了一些有帮助的内容,如消息代理和存储结果的地址、并发数量、任务列表、交换类型等。在对Celery不熟悉的时候可以通过如上信息判断设置和修改是否已生效。
现在开启另外一个终端,用IPython调用add函数:
In : from proj.tasks import add
In : r = add.delay(1, 3)
In : r
Out:
In : r.result
Out: 4In : r.status
Out: u'SUCCESS'In : r.successful()
Out: TrueIn : r.backend
Out: # 保存在Redis中
可以看到worker的终端上显示执行了任务:
[2016-06-03 13:34:40,749: INFO/MainProcess] Received task: proj.
tasks.add[93288a00-94ee-4727-b815-53dc3474cf3f]
[2016-06-03 13:34:40,755: INFO/MainProcess] Task proj.tasks.add[
93288a00-94ee-4727-b815-53dc3474cf3f] succeeded in 0.00511166098
295s: 4
通过IPython触发的任务就完成了。任务的结果都需要根据上面提到的task_id获得,我们还可以用如下两种方式随时找到这个结果:
task_id = '93288a00-94ee-4727-b815-53dc3474cf3f'In : add.AsyncResult(task_id).get()
Out: 4
或者:
In : from celery.result import AsyncResult
In : AsyncResult(task_id).get()
Out: 4
指定队列
Celery非常容易设置和运行,通常它会使用默认的名为celery的队列(可以通过CELERY_DEFAULT_QUEUE修改)用来存放任务。我们可以使用优先级不同的队列来确保高优先级的任务不需要等待就得到响应。
基于proj目录下的源码,我们创建一个projq目录,并对projq/celeryconfig.py添加如下配置:
from kombu import Queue
CELERY_QUEUES = ( # 定义任务队列
Queue('default', routing_key='task.#'), # 路由键以“task.”开头
的消息都进default队列
Queue('web_tasks', routing_key='web.#'), # 路由键以“web.”开头
的消息都进web_tasks队列)
CELERY_DEFAULT_EXCHANGE = 'tasks' # 默认的交换机名字为tasksCELERY_DEFAULT_EXCHANGE_TYPE = 'topic' # 默认的交换类型是topicCELERY_DEFAULT_ROUTING_KEY = 'task.default' # 默认的路由键是task.
default,这个路由键符合上面的default队列CELERY_ROUTES = { 'projq.tasks.add': { # tasks.add的消息会进入web_tasks队列
'queue': 'web_tasks', 'routing_key': 'web.add',
}
}
现在用指定队列的方式启动消费者进程:
❯ celery -A projq worker -Q web_tasks -l info
上述worker只会执行web_tasks中的任务,我们可以合理安排消费者数量,让web_tasks中任务的优先级更高。
使用任务调度
之前的例子都是由发布者触发的,本节展示一下使用Celery的Beat进程自动生成任务。基于proj目录下的源码,创建一个projb目录,对projb/celeryconfig.py添加如下配置:
CELERYBEAT_SCHEDULE = { 'add': { 'task': 'projb.tasks.add', 'schedule': timedelta(seconds=10), 'args': (16, 16)
}
}
CELERYBEAT_SCHEDULE中指定了tasks.add这个任务每10秒跑一次,执行的时候的参数是16和16。
启动Beat程序:
❯ celery beat -A projb
然后启动Worker进程:
❯ celery -A projb worker -l info
之后可以看到每10秒都会自动执行一次tasks.add。
Beat和Worker进程可以一并启动:
❯ celery -B -A projb worker -l info
使用Django可以通过django-celery实现在管理后台创建、删除、更新任务,是因为它使用了自定义的调度类djcelery.schedulers.DatabaseScheduler,我们可以参考它实现Flask或者其他Web框架的管理后台来完成同样的功能。使用自定义调度类还可以实现动态添加任务。
任务绑定、记录日志和重试
任务绑定、记录日志和重试是Celery常用的3个高级属性。现在修改proj/tasks.py文件,添加div函数用于演示:
from celery.utils.log import get_task_logger
logger = get_task_logger(__name__)@app.task(bind=True)def div(self, x, y):
logger.info(('Executing task id {0.id}, args: {0.args!r} '
'kwargs: {0.kwargs!r}').format(self.request)) try:
result = x / y except ZeroDivisionError as e: raise self.retry(exc=e, countdown=5, max_retries=3) return result
当使用bind = True后,函数的参数发生变化,多出了参数self(第一个参数),相当于把div变成了一个已绑定的方法,通过self可以获得任务的上下文。
在IPython中调用div:
In : from proj.tasks import div
In : r = div.delay(2, 1)
可以看到如下执行信息:
[2016-06-03 15:50:31,853: INFO/Worker-1] proj.tasks.div[1da82fb8
-20de-4d5a-9b48-045da6db0cda]: Executing task id 1da82fb8-20de-4
d5a-9b48-045da6db0cda, args: [2, 1] kwargs: {}
换成能造成异常的参数:
In : r = div.delay(2, 0)
可以发现每5秒就会重试一次,一共重试3次(默认重复3次),然后抛出异常。
本节是《Python Web开发实战》书中的第9章第三节的第一部分。