神刀安全网

爬虫架构|Celery+RabbitMQ快速入门(一)

一、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:

爬虫架构|Celery+RabbitMQ快速入门(一)

Celery+RabbitMQ是如何工作的

三、后续

下一篇文章我将具体讲讲它们在代码上的协助方式。

转载本站任何文章请注明:转载至神刀安全网,谢谢神刀安全网 » 爬虫架构|Celery+RabbitMQ快速入门(一)

分享到:更多 ()

评论 抢沙发