Celery入门

Celery是一个简单可靠的分布式任务队列，它主要关注于实时任务处理，同时也能够支持定时任务。这个项目目前在github上有14.8k颗星，是一个比较热门的项目。Celery是采用Python语言编写的，但其他语言也可以实现它的协议，或者通过webhook与之交互。Celery本身也比较精巧，据官方文档介绍，Celery的核心总共只有7000多行代码，但有14000多行测试代码，所以质量应该也还是不错的。那今天我们来一起看一下Celery的基本概念和一个小例子。

 

Celery简化的架构示意图如下

 

 

从这个图中我们可以看出，基本上Celery的架构就是一个典型的生产者-消费者模式。Celery中有一些基本的概念与术语，下面我们分别来了解一下

 

基本概念

任务（Task)

任务是被Celery的Worker执行的基本单位，一个任务一般是Python中的一个函数

@app.task
def add(x, y):
    return x + y

生产者(Producer)

生产者，也就是请求任务执行的客户端。他通过发送一个消息给broker，来要求某个任务的执行。采用delay方法能发出一个这样的message，delay()方法实际上会把工作交给apply_async()

add.delay(2, 2)
# 等效于
add.apply_async((2, 2))

消费者（Consumer)

在Celery中消费者就是是Worker，Worker本身并不执行任务。当Worker从broker接收到消息之后，会让Worker的子进程(execution pool中)执行Task。Worker可以启动多个，也可以分布在不同的机器上，所以能很好的支持水平扩展。

 

创建Worker的命令为

 celery -A celery_demo worker -l info -Q demo --concurrency=3 -n worker1@%h --autoscale=3,1

消息（Message)

任务消息是生产者发给broker的要求Worker执行任务的请求。通常消息由消息头和消息体组成，消息头描述了消息的序列化类型，消息体包含任务的名字、ID和参数，一个Json格式的消息体是长这样的

{ 'task': 'myapp.tasks.add', 'id': '54086c5e-6193-4575-8308-dbab76798756', 'args': [4, 4], 'kwargs': {}}

Broker

Broker是把消息从生产者传递到消费者的消息中间件，在Celery中，一般可以使用RabbitMQ或者Redis作为broker。也有一些其他的试验性质的broker，具体支持的列表可以参见官网文档

 

Queue

在Celery中我们可以定义多个Queue，任务可以路由到指定的Queue中，不同的Worker可以分别处理不同的Queue中的消息

 

Result Backend

Result Backend是用来存放Task执行的状态和结果的。在Celery中可以使用数据库、Redis/RabbitMQ等等作为Result Backend

 

一个例子

了解了这些概念之后，我们来看一个简单的例子。在这个例子中，我们选用redis作为我们的消息队列。你可以选择你喜欢的方式安装reids，或者也可以使用docker

docker run -d -p 6379:6379 redis

然后我们需要安装Python的Celery和redis依赖

pip install celerypip install redis

接下来我们来编写两个简单的task，分别求两个数的和与差，内容放在celery_test.py中。

from celery import Celery​app = Celery('celery_test', broker='redis://localhost')​app.conf.task_routes = {'celery_test.sub': {'queue': 'qsub'}, 'celery_test.add': {'queue': 'qadd'} } @app.taskdef add(x, y) return x+ y @app.taskdef sub(x, y) return x -y

在代码中，我们初始化了一个Celery的对象。还定义了task的路由规则，指定sub任务路由到qsub队列中， add任务路由到qadd队列中。

 

然后我们就可以启动Celery Worker了，这里我们使用命令行启动两个Worker，分别关注不同的queue

celery -A celery_test worker --loglevel=info -Q qsubcelery -A celery_test worker --loglevel=info -Q qadd

执行命令后如果一切正常的话，会出现以下日志

-------------- celery@host_name v4.4.2 (cliffs) --- ***** -----  -- ******* ---- Darwin-19.3.0-x86_64-i386-64bit 2020-04-12 > 09:55:21 - *** --- * ---  - ** ---------- [config] - ** ---------- .> app: celery_test:0x1049aeed0 - ** ---------- .> transport: redis://localhost:6379//- ** ---------- .> results: disabled:// - *** --- * --- .> concurrency: 8 (prefork) -- ******* ---- .> task events: OFF (enable -E to monitor tasks in this worker) --- ***** -----  -------------- [queues] .> qsub exchange=qsub(direct) key=qsub

 

在日志中显示了我们的app的名字celery_test，使用的redis连接信息，并没有启用Result Backend，处理任务采用prefork的方式，最大允许8个并发，并且关注一个叫qsub的队列。

 

启动Worker之后，应用就可以向broker发请求消息了，我们一般通过delay()方法来发送，如果需要更多的选项，如发送到指定的queue，设定延时执行等，可以使用apply_async()方法

add.delay(2, 2)sub.delay(4, 2)

 

用Python执行以上两句之后，在两个Worker的console中分别可以看到收到对应task并执行的日志。

[2020-04-12 10:41:20,410: INFO/MainProcess] Received task: celery_test.sub[50747bc7-9fa4-45f5-a5be-ad08b93dea09] [2020-04-12 10:41:20,413: INFO/ForkPoolWorker-6] Task celery_test.sub[50747bc7-9fa4-45f5-a5be-ad08b93dea09] succeeded in 0.0005345229999997869s: 3

 

如果生产者发送请求消息的时刻，对应的Worker还没有启动，那消息将会被保存在broker中，等Worker上线之后，任务还是可以被正常执行。

 

对于不需要返回结果的任务，那到这里差不多就够了。如果像我们用的add/sub这样需要返回结果的任务，我们在定义celery app的时候，还要指定一个Result Backend。Celery支持多种Result Backend，如SQLAlchemy/Django ORM, Memcached, Redis, RPC (RabbitMQ/AMQP)，我们甚至也可以根据celery的协议定义我们自己的backend。

 

这里我们还是使用redis作为我们的Result Backend，我们将上面那个创建Celery对象的语句改为

app = Celery('tasks', backend='redis://localhost', broker='redis://localhost')

然后重启Worker，可以看到之前打印的启动日志中的 results: disabled:// 变成了 results:  redis://localhost/

 

然后我们就可以在生产者这边获得任务执行的结果了

result = add.delay(2, 2)result.ready() # 判断任务是否完成result.get(timeout=1) # 获得结果

如果任务执行抛出了异常，那调用result.get()方法也会抛出这个异常。如果我们不想要这个异常，可以设置propagate参数

result.get(propagate=False)
result.traceback # 获得异常的stacktrace

特别要注意的是，任务执行结果的保存和传输都是要消耗Result Backend的资源的，根据使用Result Backend的不同，会有不一样的资源占用情况，比方说在redis的话，结果会作为redis的键值对保存，默认超时时间为一天。为了确保资源能够正常释放，在开启Backend的情况下，建议总是去调用一下result.get或者result.forget方法

 

关于Celery今天就介绍到这里，Celery还有很多灵活的配置项和一些高级的话题，如通过Clery Beat支持定时的任务、消息的限流、安全认证、Django框架的集成等等。对这些内容感兴趣的同学们可以查看官方文档，或者期待一下也许还会有的下文