分布式多爬虫系统——架构设计

版权声明:本文为博主原创文章,遵循 CC 4.0 by-sa 版权协议,转载请附上原文出处链接和本声明。
本文链接:https://blog.csdn.net/Bone_ACE/article/details/55000416

前言:

在爬虫的开发过程中,有些业务场景需要同时抓取几百个甚至上千个网站,此时就需要一个支持多爬虫的框架。在设计时应该要注意以下几点:

  1. 代码复用,功能模块化。如果针对每个网站都写一个完整的爬虫,那其中必定包含了许多重复的工作,不仅开发效率不高,而且到后期整个爬虫项目会变得臃肿、难以管理。
  2. 易扩展。多爬虫框架,这最直观的需求就是方便扩展,新增一个待爬的目标网站,我只需要写少量 必要的内容(如抓取规则、解析规则、入库规则),这样最快 最好。
  3. 健壮性、可维护性。这么多网站同时抓取,报错的概率更大,例如断网、中途被防爬、爬到“脏数据”等等。所以必须要做好日志监控,能实时监控爬虫系统的状态,能准确、详细地定位报错信息;另外要做好各种异常处理,如果你放假回来发现爬虫因为一个小问题已经挂掉了,那你会因为浪费了几天时间而可惜的(虽然事实上我个人会不时地远程查看爬虫状态)。
  4. 分布式。多网站抓取,数据量一般也比较大,可分布式扩展,这也是必需的功能了。分布式,需要注意做好消息队列,做好多结点统一去重。
  5. 爬虫优化。这就是大话题了,但最基本的,框架应该要基于异步,或者使用协程+多进程。
  6. 架构简明,要方便以后未知功能模块的添加。

需求如上,说的已经很清楚了。下面介绍一种架构设计,是去年做的了,现在分享一下。具体的代码实现就暂不公开了。



正文:

以下将通过解释两张图来说明架构的设计思想。
分布式多爬虫框架1

  1. 框架主要分成两部分:下载器Downloader和解析器Analyzer。Downloader负责抓取网页,Analyzer负责解析网页并入库。两者之间依靠消息队列MQ进行通信,两者可以分布在不同机器,也可分布在同一台机器。两者的数量也是灵活可变的,例如可能有五台机在做下载、两台机在做解析,这都是可以根据爬虫系统的状态及时调整的。
  2. 从上图可以看到MQ有两个管道:HTML/JS文件待爬种子Downloader待爬种子里拿到一条种子,根据种子信息调用相应的抓取模块进行网页抓取,然后存入HTML/JS文件这个通道;AnalyzerHTML/JS文件里拿到一条网页内容,根据里面的信息调用相应的解析模块进行解析,将目标字段入库,需要的话还会解析出新的待爬种子加入MQ。
  3. 可以看到Downloader是包含User-Agent池、Proxy池、Cookie池的,可以适应复杂网站的抓取。
  4. 模块的调用使用工厂模式。

分布式多爬虫框架2

  1. 这张图是上张图的另一种表述。
  2. Htmls队列和Seed是队列可以独立分开,甚至数量也可以多开,之间没有联系。完全可以灵活地根据爬虫状态和硬件环境作调整。另外8G的内容可以让Redis作为Seeds队列存放5~8千万个种子。
  3. 分布式爬虫非常关键的一点:去重。可以看到多个解析器Analyzer共用一个去重队列,才能够保证数据的统一不重复。去重队列可以放在一台机上。基于Redis实现了Bloomfilter算法(详细见《基于Redis的Bloomfilter去重(附Python代码)》),理论上8G的内存可以满足30亿条URL的去重,如果允许漏失概率再大点的话能去重更多。



结语:

要写一个支持分布式、多爬虫的框架,具体的实现上还是有一定难度的。在实现主要功能以外,还要注意做到代码严谨 规范,爬虫高效 健壮的要求。做完这些以后,你定会成长不少!

今天就分享这些,欢迎交流!



转载请注明出处,谢谢!(原文链接:http://blog.csdn.net/bone_ace/article/details/55000416

展开阅读全文

没有更多推荐了,返回首页