分布式异步任务队列 Celery + rabbitmq (or redis )

当我们需要处理一些比较耗时的任务时,我们就需要考虑启用“异步”这个概念。
比如以下两种情况:

一,频繁读写
比如说,现在你一条“微博”,如果是使用 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数据库,也可以当成小型的队列服务来使用。

这里有份 rabbitmq 和 redis 的并发对比 “<<redis作为消息队列与RabbitMQ的性能对比>>

 

 

发表评论

电子邮件地址不会被公开。 必填项已用*标注