写作背景介绍
在celery简单入门中已经介绍了写作的背景，这篇文章主要是深入介绍celery的使用技巧。在实际的项目中我们需要明确前后台的分界线，因此我们的celery编写的时候就应该是分成前后台两个部分编写。在celery简单入门中的总结部分我们也提出了另外一个问题，就是需要分离celery的配置文件。
第一步
编写后台任务tasks.py脚本文件。在这个文件中我们不需要再声明celery的实例，我们只需要导入其task装饰器来注册我们的任务即可。后台处理业务逻辑完全独立于前台，这里只是简单的hello world程序需要多少个参数只需要告诉前台就可以了，在实际项目中可能你需要的是后台执行发送一封邮件的任务或者进行复杂的数据库查询任务等。
import time
from celery.task import task
@task
def say(x,y):
time.sleep(5)
return x+y
第二步
有了那么完美的后台，我们的前台编写肯定也轻松不少。到底简单到什么地步呢，来看看前台的代码吧！为了形象的表明其职能，我们将其命名为client.py脚本文件。
from celery import Celery
app = Celery()
app.config_from_object('celeryconfig')
app.send_task("tasks.say",['hello','world'])
可以看到只需要简单的几步
- 声明一个
celery实例。 - 加载配置文件。
- 发送任务
第三步
让我们完成celery的配置吧！官方的介绍使用celeryconfig.py作为配置文件名，这样可以防止与你现在的应用的配置同名。
CELERY_IMPORTS = ('tasks')
CELERY_IGNORE_RESULT = False
BROKER_HOST = '127.0.0.1'
BROKER_PORT = 5672
BROKER_URL = 'amqp://'
CELERY_RESULT_BACKEND = 'amqp'
可以看到我们指定了CELERY_RESULT_BACKEND为amqp默认的队列！这样我们就可以查看处理后的运行状态了，后面将会介绍处理结果的查看。
第四步
启动celery后台服务，这里是测试与学习celery的教程。在实际生产环境中，如果是通过这种方式启动的后台进程是不行的。所谓后台进程通常是需要作为守护进程运行在后台的，在python的世界里总是有一些工具能够满足你的需要。这里可以使用supervisor作为进程管理工具。在后面的文章中将会介绍如何使用supervisor工具。
celery worker -l info --beat
注意现在运行worker的方式也与前面介绍的不一样了，下面简单介绍各个参数。
-l info与--loglevel=info的作用是一样的。--beat周期性的运行
运行后可以看到下面这样的输出。
第五步
前台的运行就比较简单了，与平时运行的python脚本一样。
python client.py
此时应该是什么也没有看到，脚本也没有返回任何数据。运行后立即结束，这是正常的。我们看到后台会发现已经输出了一些数据，这些内容应该大致是显示如下信息。
现在前台的任务是运行了，可是任务是被写死了。我们的任务大多数时候是动态的，为演示动态工作的情况我们可以使用终端发送任务。
在python终端导入celery模块声明实例然后加载配置文件，完成了这些步骤后就可以动态的发送任务并且查看任务状态了。注意在配置文件celeryconfig.py中我们已经开启了处理的结果回应模式了CELERY_IGNORE_RESULT = False并且在回应方式配置中我们设置了CELERY_RESULT_BACKEND = 'amqp'这样我们就可以查看到处理的状态了。
从图中，我们可以看到任务发送给celery后马上查看任务状态会处于PENDING状态。稍等片刻就可以查看到SUCCESS状态了。这种效果真棒不是吗？在图像处理中或者其他的一些搞耗时的任务中，我们只需要把任务发送给后台就不用去管它了。当我们需要结果的时候只需要查看一些是否成功完成了，如果返回成功我们就可以去后台数据库去找处理后生成的数据了。
总结
现在我们的celery看起来有模有样了,不过我们的结果并没有保存在我们最喜欢的数据库中。大多时候我们都希望计算结果能够保存在一个常规数据库中而不是消息队列中，那么celery应该怎么配置才能把数据保存到数据库中呢？下篇文章我们就使用mongodb保存我们的计算结果吧！让数据持久化吧！