最近的项目要使用异步的任务队列，初步选用了Celery，比较轻量级，但是对Task，Broker，Worker等概念有些理解的不透彻，找到以下文章，甚是透彻。
当我们需要处理一些比较耗时的任务时，我们就需要考虑启用“异步”这个概念。
比如以下两种情况：
一，频繁读写
比如说，现在你一条“微博”，如果是使用 push 的机制，那则需要将这条“微博”告知所有关注你的人。
（这里是假设。实际的微博是使用推拉结合的方式）
关注你的人是100，则 insert 100次。
假如你是个大V，关注你的人有100000人,则需要 insert 100000次。
如果使用同步的方式，那恭喜你，你发完一条微博，这个时间够你喝杯咖啡了。
二，使用“不可靠”的服务
这里的不可靠，指的并不是它不能使用，而是指它不稳定。
当你调用第三方的短信接口，app push接口，无法预计调用接口的时间，这次调用，可能使用0.01s，但下次则变成3s。
这在生产环境是完全可能发生的。高并发，网络异常都可能造成这种情况。
如果这个任务不需要及时返回结果，那我们就可以将这些任务丢给后台去处理，某些实时性要求比较高的任务，还是只能同步进行。
常规的使用场景：短信服务、图片处理服务、群发email、第三方接口调用。
mx
在这里我推荐 celery 。Celery 是一个异步任务队列/基于分布式消息传递的作业队列。
celery_128
这里有几个概念，task、worker、broker。
顾名思义，task 就是老板交给你的各种任务，worker 就是你手下干活的人员。
那什么是 Broker 呢？
老板给你下发任务时，你需要 把它记下来， 这个它 可以是你随身携带的本子，也可以是 电脑里地记事本或者excel，或者是你的 任何时间管理工具。
Broker 则是 Celery 记录task的地方。
作为一个任务管理者的你，将老板（前端程序）发给你的 安排的工作（Task） 记录到你的本子（Broker）里。接下来，你就安排你手下的IT程序猿们（Worker），都到你的本子(Broker)里来取走工作（Task）
tasks
Celery本身不存储“数据”，需要配合各种后端消息队列一起工作。
官方推荐的是 rabbitmq。
rabbitmq有些臃肿（需要安装erlang）,但性能比较稳健。在大数据高并发的情况下，出队与入队的速度基本持平。
redis， 作为一个支持list的key-value数据库，也可以当成小型的队列服务来使用。