一、Celery和RabbitMQ简单介绍
Celery是一个基于Python开发的分布式异步消息队列，可以轻松实现任务的异步处理。它的基本工作就是管理分配任务到不同的服务器，并且取得结果。至于说服务器之间是如何进行通信的？这个Celery本身不能解决。
Celery在执行任务时需要一个消息中间件来接收和发送任务消息，以及存储任务结果，一般使用RabbitMQ 或 Redis，我们这里只讨论Celery+RabbitMQ，其他的组合方式读者可以查阅更多资料。
RabbitMQ是一个由Erlang语言开发的AMQP的开源实现。AMQP即Advanced Message Queue，高级消息队列协议。它是应用层协议的一个开放标准，为面向消息的中间件设计，基于此协议的客户端与消息中间件可传递消息，并不受产品、开发语言等条件的限制。
在Celery+RabbitMQ组合中，RabbitMQ作为一个消息队列管理工具被引入到和Celery集成，负责处理服务器之间的通信任务。
那么有一个疑问：RabbitMQ作为消息管理系统已经可以实现异步的发送消息，为什么还要使用Celery?
Celery相当于包装了一个现成的系统，可以方便的在项目中操作RabbitMQ这个消息队列介质，减少在RabbitMQ上编写脚本的任务。最直接的例子就是在Celery Python里，只需要config一下settings，然后就可以用decorator轻松使用消息队列，而不用在RabbitMQ上编写复杂的脚本。
当然，Celery也支持和Redis、MongoDB之类的组合，原因是RabbitMQ尽管足够强大，但对于一些相对简单的业务环境来说可能太多（复杂）了一些。
二、Celery+RabbitMQ是如何工作的？
关于Celery和RabbitMQ的协作方式，可以通过工作上的一些案例来说明：
假设A公司最近在开下年度工作会议，会议上要确定下一年的工作内容和计划，参会人员有老板（下发任务者）、部门主管（Celery分配任务者）、部门员工（工作者）、老板秘书（沟通协调者RabbitMQ）。
那么这场会议首先需要确定的是下一年的具体工作内容，这里就称之为“任务内容”。比如老板说我们下一年要开发出一款社交类APP产品，部门主管表示赞同，于是便愉快地定下了具体的工作任务（task），当然开发一款社交类APP产品是这个项目的总任务，其中可以细分成很多小的任务，比如业务流程是怎么样的？界面怎么设计等。
在确定了具体工作任务后，老板便把这个项目交给了部门主管（Celery），部门主管确定部门员工中谁去完成这项任务，于是指定某个人（Worker），也可以多个人。
发布工作任务的人是老板（下发任务者），他指定了部门主管（Celery）什么时候去完成哪些任务，并要求获取反馈信息。但有一点需要注意，老板只管布置任务，不参与具体的任务分配，这个任务分配的工作是交给部门主管（Celery）去执行。
项目之初，老板（下发任务者）通过公司会议将任务传递给部门主管（Celery），部门主管通过部门会议将任务分配给员工（Worker），过段时间再将任务结果反馈给老板。然而随着任务越来越多，部门主管发现任务太多，每个任务都要反馈结果，记不住，也容易弄乱，导致效率下降。
在召开会议商量了一番后，老板秘书（沟通协调者RabbitMQ）站起来说：“我有个提议，老板每天将布置的任务写成一张纸条放到我这，然后部门主管每天早上来取并交给员工，至于纸条上的任务如何分配，部门主管决定就行，但是要将结果同样写一张纸条反馈给我，我再交给老板。这样老板只负责下发任务，我只负责保管任务纸条，部门主管只负责分配任务并获取反馈，员工只负责按任务工作。大家职责都很明确，效率肯定会更高。”至此，老板与员工的沟通问题也解决了。
任务的处理方式如下图1-1:
三、后续
下一篇文章我将具体讲讲它们在代码上的协助方式。
