APP下载

基于协程模型的分布式爬虫框架

2014-10-28杨济运刘建勋姜磊彭桃文一凭卢厅

计算技术与自动化 2014年3期
关键词:爬虫高性能分布式

杨济运+刘建勋+姜磊+彭桃+文一凭+卢厅

收稿日期:2013-05-28

基金项目:国家自然科学基金项目(61272063,61100054);教育部新世纪优秀人才支持计划项目(NCET-10-0140);教育部人文社科基金项目(12YJCZH084);湖南省教育厅资助项目(12C0119);湖南省科技计划项目(2013FJ3002);湖南科技大学资助项目(E51368)

作者简介:杨济运(1990—),男,浙江温岭人,硕士研究生,研究方向:网络舆情。

通讯联系人,E-mail:iamyoung001@gmail.com

文章编号:1003-6199(2014)03-0126-08

摘 要:网络爬虫主要受到网络延迟和本地运行效率的限制,传统的基于多线程的网络爬虫架构主要为了消除网络延迟而没有考虑到本地运行效率。在高并发的条件下,多线程架构爬虫由于上下文切换开销增大而导致本地运行效率降低,同时使得网络利用率下降,如何能够在最大化利用网络资源的情况下减小系统本地开销是一个需要研究的问题。针对以上问题,本文提出基于协程的分布式网络爬虫框架来解决,从开销、资源利用率、网络利用率上对协程框架和多线程框架进行了分析,并基于协程实现了一个分布式网络爬虫。实验表明该框架无论从开销、资源利用率和网络利用率上相对于多线程框架有比较明显的优势。

关键词:协程;分布式;高性能;爬虫

中图分类号:TP311 文献标识码:A

A Distributed Crawler Framework Based on Coroutine Model

YANG Ji-yun, LIU Jian-xun, JIANG Lei,PENG Tao, WEN Yi-ping,LU Ting

(Key Laboratory of Knowledge Processing and Networked Manufacturing,

Hunan University of Science and Technology, Xiangtan,Hunan 411201, China)

Abstract:Web crawler is mainly limited by the network latency and local resource. The traditional framework of web crawler, which is based on multi-threads, is mainly to eliminate the network latency but failed to take the local resource limitation into account. Under the high concurrent, multi-threads architecture will result in a poor running efficiency because of the increasing of the context switch. So studying on how to make maximum usage of network resources and also considering the local resource limitation becomes a necessary. To solve the above problems, this paper will propose a distributed crawler framework based on coroutine. First we have analyzed the overhead, resource utilization and network utilization between coroutines and threads, and implemented a web crawler based on coroutine. Experiments had shown that our architecture for a distributed web crawler based on coroutine is better than threads-based web crawler.

Key words:coroutine;distribution;high-performance;web crawler

1 引言

随着互联网发展,尤其是近几年网络上的用户自己创造内容(UGC)和社交网络的发展,数据呈爆炸式增长。自2003年开始,中国的网页规模基本保持翻番增长,2010年网页数量达到600亿个,年增长率为78.6%[1]。由于网络的增速发展导致一年产生的信息量比以往所有信息量的总和还要多。这对搜索引擎提出了更高的要求,搜索引擎必须能在不降低搜索质量的前提下索引比以往更多的数据,而作为搜索引擎的基础组件的网络爬虫必须能够在较短的时间内完成对目标网络的收集。

网络爬虫的工作原理如下: 从一个初始URLs集(称为种子URLs)出发, 从中获取一个URL ,下载网页, 从网页中抽取所有的URLs , 并将新的URLs添加到URLs队列中。然后爬虫从队列中获取另一个URL。重复刚才的过程, 直到爬虫达到某种停止标准为止[2]。

尹江等[3]提出目前爬虫的自身瓶颈主要受到网络延时和本地运行效率的限制,而两者主要表现为程序本地化资源占用、程序切换开销和网络利用率问题。为了突破网络延时的限制,目前绝大部分的爬虫系统采用阻塞同步模型(多线程模型)的设计,以充分利用网络带宽,大部分的网络爬虫都是基于多线程的架构[4]。然而这并不能完全疏通爬虫的效率瓶颈[5],周德懋等[6]指出使用多线程模型在随着连接的增多,线程的切换将是一个很大的开销。李晓明等[7]提出为最大化利用网络资源,同时缩短线程执行周期,应该使用非阻塞异步I/O模型而非阻塞同步模型。但是基于事件的非阻塞异步I/O模型编程比较复杂,在绝大部分连接处于活动的状态下会有轮询的开销,并且在事件响应的时候有惊群现象。因此虽然非阻塞异步I/O模型相对于多线程模型有更好的性能,但是由于难度较大,仅有少数爬虫使用[8]。

针对现有爬虫问题,需要使用非阻塞异步I/O模型来尽可能的提高网络利用率,同时兼顾本地资源使用和程序切换开销,由此本文提出了基于协程分布式网络爬虫架构。协程是一种程序组件,是由子例程(过程、函数、例程、方法、子程序)的概念泛化而来的,子例程只有一个入口点且只返回一次,而协程允许多个入口点,可以在指定位置挂起和恢复执行[9]。从定义可见协程是一个程序组件如同线程和进程,但是属于非阻塞异步I/O模型,线程和进程并发是多个子例程通过操作系统时间片轮转来实现,而协程是单个子例程通过用户自己控制调度实现并发。协程由于自己控制调度,无需CPU参与,可以减少大量的无用切换开销,并且由于本身轻量级,切换开销也比较小,并且其由于非阻塞异步I/O模型而具有更高的网络利用效率。

本文的组织结构为:第2节将简要介绍相关工作;第3节给出了爬虫的设计框架和设计细节;第4节介绍协程与多线程的对比;第5节为实验和分析,以验证框架的可行性和有效性。最后对全文进行了总结,并展望了下一步的工作。

2 相关工作

爬虫的历史非常久远,爬虫的编程模型也经过多种变化,在本节首先对于爬虫模型的变化进行介绍再介绍,之后提出目前爬虫的不足与本文解决方案相关的研究。

2.1 基于多进程框架的网络爬虫

网络爬虫从早期网络刚开始萌芽的时候就诞生了,刚开始使用的是多进程模型,此时仅仅是考虑多并发来利用网络,没有考虑爬虫的扩展性问题。具有代表性的为1993年提出来的RBSE spider[10],1994年提出的MOMspider[11]。这个阶段的爬虫为了克服单线程的I/O等待问题,引入了多进程并发,MOMspider通过15个进程进行并发爬取,然而这时候的爬虫没有对系统的可扩展性和同步进行设计。由于受到当时硬件和进程本事占用资源的限制,爬虫的并发数处于很低的状态,只能说部分解决了I/O等待问题。

2.2 基于异步非阻塞的网络爬虫

为了提升效率,爬虫开始使用异步I/O模型,最开始采用的是在1997提出的Internet Archive[12]和1998年Google的早期爬虫[13]。Internet Archive的每个爬虫使用64个异步下载端进行并行爬取,并抽取链接。早期的Google爬虫系统使用单线程的异步I/O模型,一次维持300个连接并行爬行。

但是由于早期使用的异步机制是听过监听事件来实现,与顺序编程模型有比较大的不同,导致爬虫与存储组件、分发组件等结合比较麻烦。

2.3 基于多线程框架的网络爬虫

由于使用异步I/O模型需要程序员自己对线程进行控制,网络规模越来越大,导致使用异步模型更加的复杂,而同步I/O模型将线程的管理交给了操作系统,从编程模式上相对于异步I/O模型使用比较简单[14],从可扩展性上考虑,爬虫开始使用多线程模型,这个模型也被沿用至今。这个期间的代表爬虫为1999年设计的Mercator和2004年设计的Ubicrawler。Mercator采用Java的多线程同步方式实现并行处理,并加入了很多优化策略如DNS缓冲、延迟存储等以提升爬虫运行效率。Ubicrawler主要是通过对爬虫进行完全分布性和高容错性的实现来消除单点故障。

2.4 现有爬虫架构不足

互联网飞速发展,网络的规模翻番增长,传统使用的多线程爬虫碰到了越来越多的问题。首当其冲就是多线程上下文切换导致系统性能降低的问题。由于机器性能和网络带宽的发展,单台机器的线程并发数相对于以前提高不少数量级,上下文开销随着并发数的提高变得越来越大。很多学者开始研究多线程之外的选择,Ding等[15]于2006年使用异步I/O方式实现了分布式爬虫,取得了满意的效果。Li等人[16]于2007年发现线程上下文切换对于系统运行效率影响随着系统负载的增加而增加,在高并发的条件下,上下文切换会成为性能杀手。Yin等[20]2008年做了同步模型与异步模型的对比,发现异步模型相对同步模型获得了比较大的提升。Zhou等[17]在2009年提出随着连接的增多,线程的切换将是很大的开销,非阻塞异步I/O模型具有扩展性强、性能优越等特点是高性能网络编程的最佳选择。Shaver等[3]在2012年提出高并发条件下,协程计算模型是更优的选择。

由以上工作可知:网络爬虫的编程架构从多进程架构变化到多线程,而近几年的研究从多线程转为异步非阻塞模型。相对于多线程模型,单线程异步模型利用消息通知机制从而使网络利用率上更高,随着时间的推移更多的消息组件和存储组件开始支持异步事件监听机制。但是由于事件监听机制在高并发条件下需要对本地维持的连接进行轮训来,也使得效率下降。

2.5 协程相关研究

协程最先由conway等[18]提出,后来由Donald Knuth对协程进行定义:子例程是协程的特例[19]。协程的创建是在用户态通过保存栈的状态实现的,无需内核的参与使得协程的创建速度非常快,甚至有些通过抛弃栈用程序代码执行位置来记录协程状态,称为Stackless Coroutine,本文即使用这种模型。由于协程是在用户态通过栈实现,协程占用的资源相对于线程也非常小。

表1是协程与事件监听模型在实现上的对比,可以看到协程通过yield关键字来切换,而事件监听模型是通过对于事件的监听来调用相应的回调函数,但是模型跟复杂,也不容易与其他组件结合。而线程调度由CPU控制,对于用户不可见,由此产生低效。通过用户层来模拟CPU调度,协程大大降低了切换的开销,由此降低了程序的运行开销。程序由用户自己控制调度,由此也使得程序减少了无谓的切换,使得资源利用率更高。I/O bound是指程序运行时间主要在等待I/O完成的时间上,而爬虫就是I/O bound问题。协程在碰到I/O等待的时候,自动切换到另外一个协程而无需用户介入,这种机制非常适合I/O bound场景,由此想到使用协程来解决目前爬虫所碰到的问题。

miller等[11]对于协程进行了全方面的阐述,并指出协程是未来发展的方向,edward[12]指出在并发编程中,由于线程的很多问题,应该以协程作为开发的第一选择。Xiao等[2]研究了协程在线程交互之间的使用,相对于使用线程获得了非常大的提升;Shaver等[3]详细介绍了协程的计算模型Nanz等[1]提出在分布式计算中应该使用协程来解决当前碰到的分布式问题。

表1 协程与基于事件监听的异步模型对比

3 基于协程的分布式爬虫框架

本节,首先将讨论一个爬虫架构所需要的一些目标,然后给出本文框架的详细设计。

设计一个爬虫需要满足以下几个目标:

低消耗和高性能:这是爬虫内在属性的需求,爬虫需要尽可能的使用最小的资源达到最高的性能。这里指的消耗不仅仅是爬虫对于一个页面的爬取时间消耗,同样也是爬取一个页面对系统资源的消耗。

健壮性:健壮的爬虫需要能够容忍一些节点的失败,对于一些关键数据进行多台冗余备份,防止单点故障,具体采用集群方案来进行冗余备份和提高性能。

速度可控:对于服务器管理者来说,他们会使用一些策略来限制爬虫的并发连接和速度。如果爬虫速度比较快,对于同一台服务器进行频率比较高的访问,会影响服务器的对外服务能力。为了对服务器友好,针对单台服务器本文设计了一种频率控制算法,算法如表2:

表2 频率控制算法

爬虫获得一个服务器的连接地址,第一次根据配置文件中设置的爬取间隔爬取,以后根据频率控制算法动态调整。

可扩展性:现在网络的数据量非常的大,单台机器远远不能满足对于爬取的需求,一个爬虫的可扩展性成为现在爬虫的基本需求[17]。理想的爬虫的爬取数据随着机器数量的增加而线性增长。通过设计消息队列来分发任务,将消息的动态调整和管理交给了队列,由此形成一个server-worker消息分发模型,基本形成了添加机器对于系统效率的线性提升。

通过以上的目标描述,现介绍基于协程的爬虫框架具体实现方案及实现以上爬虫目标所开展的具体工作。

图1是爬虫的框架图,整体主要由9部分组成。整个数据流向为:首先从队列取出一个URL,并经过验证模块,如果网页有访问限制 (需要用户名、密码),从配置文件中读取用户名、密码进行验证,经过验证之后将URL发送到非阻塞异步下载模块。待网页下载完成之后,对网页进行解析,将解析出来的内容存入MySQL集群,MySQL集群主要存储今后需要处理的数据;解析出来的链接发送到连接检查器,主要对新解析出来的连接进行去重。调度模块根据下载情况和队列情况对队列内容进行动态调整。日志模块会对爬虫的工作情况、爬取工作时间、失败和错误等信息进行记录。Redis集群作为连接检查器的后端存储。消息队列来负责分发url数据,由此获得线性扩展。

A.认证模块

我们的爬虫尽可能作为一个通用的框架,使用户可以对于不同的网络对象进行爬取,而不仅仅是针对网络页面,认证模块主要是针对社交网络的爬取。由于社交网络需要认证才能进行公开流爬取,一般社交网络通过OAuth来进行认证,通过将Oauth数据存储于文件中,在Oauth过期之前,对认证信息进行存储,下次认证直接从文件中读取。这个模块中默认内置了Twitter和新浪微博的OAuth模块,为了扩展性,预留了user_login接口,这个接口是对需要认证的网页提供用户名、密码。对于不同的网络对象,可以对这个接口进行覆写达到认证的目的。

B.协程下载模块

这是爬虫最耗时的部分,通过对于不同模型的分析,最终选择使用协程机制来作为爬虫的实现机制。

爬虫运行过程中,I/O耗费时间记为Ti,而对于进入I/O等待和I/O等待结束之后的处理时间之和记为Tc,将Tc和Ti之比Tc/Ti记为T。在网络带宽比较小的情况下,Tc相对于Ti是一个很小的开销,即T是一个很小的值,在这种情况下,需要关注的是如何最大化利用网络而无需关心本地运行资源。随着带宽的增大,程序的并发数也越来越大,Ti变得越来越小,T的值变得越来越大,此时本地运行资源消耗变成不得不考虑的问题,协程就是在高并发条件下非常好的解决资源和开销问题的解决方案。

如果有两个线程A和B,A和B在单独运行时都需要10 秒来完成自己的任务,而且任务都是运算操作,A、B 之间也没有竞争和共享数据的问题。现在A、B两个线程并行,操作系统会不停的在A、B两个线程之间切换,达到一种伪并行的效果,假设切换的频率是每秒一次,切换的成本是0.1秒,总共需要 20 + 19 * 0.1 = 21.9 秒,此时每个线程的T值为0.095(1.9/2/10=0.095)。如果使用协程的方式,由于可以用户控制调度,先运行协程A,A结束的时候让位给协程B,只发生一次切换,总时间是20 + 1 * 0.1 = 20.1 秒,此时对于每个协程T值为0.005(0.1/2/10=0.005)。从运行时间和T值上都可以看到协程相对于线程的优势。

C.HTML解析器

HTML解析器主要使用多策略联合页面抽取算法[18]对网页进行解析。通过基于libxml对网页内容进行分析,将网页原始内容读入内存构建DOM树,利用页面抽取算法提取页面正文存入MySQL集群。对网页中的链接通过正则表达式来匹配,对抽取出的连接送到链接检查模块进行下一步处理。

D.连接检查模块

连接检查模块有两个功能:一是对新抽取的链接进行检查,是不是已经爬取过这个连接;二是对这个新的链接进行检查,是不是一个有效的连接。通过对链接进行hash计算,将对应的值存入redis集群的set中进行检查是否已经是被爬取过,如果是未爬取过的链接,将检查其有效性,最终生成链接、错误代码和错误次数的三元组,将其发往调度模块做下一步处理。

E.调度模块

调度模块对收到的三元组组做下一步处理。造成从连接检查模块返回过来错误的原因有很多,可能是由于对方服务器的暂时宕机或者网络不通形成的,所以需要对这些连接进行多次查询。如果是正常的链接,将其发送到redis集群中,消息队列将从中取出数据进行内容分发。对于返回错误信息的三元组,将其发给日志模块做进一步处理。

F.日志模块

日志模块从调度模块接收三元组,检查code的值,如果是404、410等,将这些记录到日志文件中;如果code是500、503等,通过对三元组扩充,添加等待时间称为四元组,将这个四元组发给连接检查模块。

G.Redis集群

Redis作为内存数据库,访问速度非常快,同时具有持久化功能,非常适合高速的处理。Redis内置数据结构比较丰富,内置set是一个非常好的查重功能模块,时间复杂度为O(1)。使用Redis作为系统链接检查模块的后端存储和消息队列的持久化方案,由于Redis目前还没有原声支持集群功能,通过实现一致性hash算法,对生成链接的hash值进行分发达到集群功能。

H.MySQL集群

MySQL集群主要用来爬取出来的内容进行存储。单台MySQL机器容易造成单点故障,用集群解决这个问题,而且集群访问速度相比单台更快,本文框架中使用的集群由2个master和3个slaver组成。

I.消息队列

目前有很多消息队列产品,如apache的ActiveMQ,vmware的RabbitMQ,但是由于使用性和扩展上比较复杂,没有可持续化的功能,本文中实现了一个基于Redis的消息队列来进行任务的分发,存取数据通过http进行。由于不同机器之间没有其他消耗,使用消息队列基本上达到了下载速度跟机器成线性增长。

4 协程与线程对比

本节将对协程与多线程爬虫框架在本地利用效率、CPU开销和网络利用率上进行对比。

4.1 本地资源效率对比

从进程组成来看,一个进程是一个多元组,P=(p,h,f,c,s)。其中P代表进程;p是可执行的程序代码、程序数据与堆栈;h和f分别是执行程序代码需要的硬件和软件资源;硬件资源包括CPU、特殊功能寄存器、内存和磁盘等;软件资源包括内核数据结构以及相关所有信息资源;s代表进程运行的各种状态;c是程序运行期间需要的控制信息。

从进程创建过程来看,进程创建所需要的时间和资源比较多;而从CPU执行程序需要的上下文考虑,只需要程序计数器、执行堆栈、通过寄存器和状态标志,由此对于进程单位进行细分形成线程。而协程通过外部控制,自己控制堆栈和状态,从而更加精简。如表3所示,线程是一个二元组T=(t,s),其中t是线程代码、程序数据和堆栈;s是线程运行的各种状态,而协程是一元组C=(t),可见协程所携带的数据变得越来越少。相对于进程和线程,协程更加的轻量级,在创建和切换上耗费的资源更小。多线程共享同一地址空间和其他资源,由于线程有进程的某些性质,所以被成为“轻量级进程”,而协程处于同一线程之内,共享一个线程数据,被称为“轻量级的线程”。由此可见使用协程作为爬虫设计的方案在本地资源占用上是最优选择。

表3 进程、线程、协程对比

4.2 CPU开销对比

在多线程环境中,CPU进行进程切换时,需要对当前线程的运行环境进行保存;然后加载需要调度的下一个线程,最后从程序计数器指向的位置开始运行。从切换过程可以看到,切换过程涉及到进程环境保存和恢复,由于进程携带的信息比较多,切换开销比较大。

爬虫需要进行高并发连接,如果使用多线程方案,线程之间的切换是个巨大的开销。创建线程对于资源的需求相对于协程比较大,服务器创建线程的数量受到服务器资源的限制。从线程创建所需内存、创建的时间和运行效率上看,多线程都不是一个很好的解决方案。线程虽然是对进程进行精简,降低上下文切换开销,在高并发的环境下依然不能忽视。

协程由于是自己控制切换与调度,可以最高效的进行调度而无需CPU的参与;其次由于协程本身比较轻量级,在切换开销上非常的少,是理想的高并发解决方案。

4.3 网络利用率对比

由于协程通过自主高效的切换管理,可以最大化的利用网络,而线程是由CPU调度导致出现很多网络的浪费现象。

图2是两种方案在3个并发数时的对比,左图是协程在一次爬取任务的切换情况,右图是线程的切换情况。从图2可以看出,协程通过自主的高效控制,只在IO等待的时候才进行切换,没有无效时间的开销,可以高效的完成一次爬取任务,完成相同的一次任务,协程方案比线程方案节省了8t的时间。协程方案可以在同样时间内获取更多的数据,从而更高的利用了网络效率。

综上所述,在爬虫应用场景下,协程是很好的解决方案。

5 实验分析

基于前面的分析,本节将对基于协程的爬虫架构和基于多线程的爬虫架构进行实验对比,从网络利用效率、本地资源占用和CPU开销进行分析。为了消除外部网络不稳定对实验的影响,实验数据采取的是内网存储服务器上的4000000个20k的文件(80G)。本实验的微机配置如为Intel(R) Core(TM) i3 CPU,3.20GHZ处理器,4G内存,操作系统为Ubuntu 12.04,网络为10M带宽共享。由于带宽限制,过高的并发数量将导致网络超时,而10M带宽的理论上限是1250k/s的下载速度,根据实验环境,网络利用率对比实验使用的线程上限是60(1250k/20k=62.5)个。为了测试本地资源效率和CPU开销,本文做了更高并发效率的实验来验证系统在高并发条件下的优势。

5.1 本地资源效率对比实验

在程序本地资源利用方面,主要考察了在不同并发数下所占用的内存情况,下图分别显示了基于协程与基于线程的爬虫进程所占用内存的情况。从图3(a)中可以看到常驻内存随着并发数的增加呈现近似线性增长,在图3(b)中看到两者真实内存随着并发数的增加而增加,但是协程所占用的内存相对于线程更少,增加速率也更低,两者真实内存的差值有扩大的趋势,可见协程的实现方案想对于线程在内存使用上具有占用更低的优势。

5.2 CPU开销对比实验

在CPU开销方面,通过利用不同的并发数,来测试CPU上下文切换的开销情况,通过设置并发数从0到300来进行对比,CPU开销的计算通过理想运行时间和实际运行时间的比值来衡量。首先介绍程序理想运行时间和实际运行时间,理想运行时间是忽略程序的生成时的初始化和上下文切换时间所计算出来的运行时间,而实际运行时间是程序实际从开始到结束的运行时间。

由于需要做高并发的对比实验,但是由于网络限制,过高的并发数量会导致网络拥塞而出现大量的网络超时,并且为了消除网络传输和文件存储等开销对于计算上下文切换的影响,在实验中将系统中的下载模块替换为休眠时间5秒钟。通过30组效果对比,每组做3次试验来取平均值以尽可能消除系统本身运行对于上下文切换的开销的影响,试验结果如图4所示,从表中可以看出协程的开销一直低于线程的开销。从并发数100开始,线程开销的增加速度加快,协程开销的增加速度相对平稳,两者之间的开销差距变得越来越大。

由于刚开始并发数比较小,CPU对于调度和切换开销还在可接受范围之内,随着并发数的增加,CPU对于调度和上下文的切换开销变得越来越大,而协程的调度不需要CPU参与,所以随着并发数的增加,协程的开销并没有显著的增加。由此可见,协程是更适合高并发的编程模式。

5.3 网络利用率对比实验

对于网络资源利用率方面,通过相同时间内的数据采集量作为对比依据,由于网络是共享的,为了尽可能减少局域网内网络流量对实验的影响,将实验在晚上进行。

图5(a)是协程方案和多线程方案在一个周期内采集数据的对比,分别在不同的时间段进行了10个周期的对比实验。从图5中可以看出,在同样的采集周期之内协程方案能够比线程方案采集更多的数据。在我们实验的十个周期之内,线程方案在一个周期之内平均采集了1.71GB的数据量,而使用协程可以采集2.1GB的数据量,相比之下协程可以获得22. 8%的效果提升。

图5(b)是网络利用效率的累积分布图。横轴所表示的是爬虫的运行周期,以30min为一个爬取周期;纵坐标为爬虫周期内累积所采集的数据量,以GB作为单位间隔。经过5个小时的爬取,获取数据量的相差为3.793GB。

从上述实验可以证明,本文中提出的基于协程的分布式爬虫框架想对于传统的线程解决方案具有占用内存更低、开销更小、效率更高等优点,尤其是在高并发条件下,协程在CPU调度和上下文切换上的优势更加的明显。

6 结论与展望

本文针对传统爬虫解决方案在高并发条件下的的不足提出了一个基于协程的分布式爬虫框架,对于爬虫目前所受到的网络和本地运行瓶颈进行分析,提出爬虫主要需要克服开销、本地利用率和网络利用率的问题。针对以上3个问题提出了我们的解决方案,首先分析了方案的可行性,并通过实验验证了方案对于传统方案的提升。实验结果表明我们的方案可以在更小的内存利用率、更小的系统开销的情况下,获得更高的网络利用率。

由于网络限制,目前对于工作线程的上限设置为60,根据开销情况,如果并发数更高时,传统的网络爬虫的CPU开销将会越来越大,在这种情况下,本文提出的基于协程的爬虫架构将有更好的效果,将来工作将会研究更高网络并发数下爬虫的运行情况。

参考文献

[1] Nanz, Sebastian, Scott West, and Kaue Soares da Silveira. “Examining the Expert Gap in Parallel Programming”. Euro-Par 2013 Parallel Processing[J]. Springer Berlin Heidelberg, 2013. 434-445.

[2] XU X,LI G.Research on Coroutine-Based Process Interaction Simulation Mechanism in C++[J].In AsiaSim 2012, ed: Springer, 2012, pp. 178-187.

[3] SHAVER C,LEE E A.The coroutine model of computation [J].In Model Driven Engineering Languages and Systems, ed: Springer, 2012, pp. 319-334.

[4] FIELDING R T.Maintaining distributed hypertext infostructures: Welcome to MOMspider's web[J].Computer Networks and ISDN Systems, 1994, 27(2):193-204.

[5] M. BURNER.Crawling towards eternity: Building an archive of the World Wide Web[J]. Web Techniques Mag., vol. 2, 1997.

[6] BRIN S,PAGE L.The anatomy of a large-scale hypertextual Web search engine[J]. Computer Networks and ISDN Systems, vol. 30, pp. 107-117, 1998.

[7] HEYDON A,NAJORK M.Mercator: A scalable, extensible web crawler[J].World Wide Web, vol. 2, pp. 219-229, 1999.

[8] Y.-X. Ding, X.-L. Wang, L.-B. Lin, Q. Zhang, and Y.-H. Wu.The Design and Implementation of the Crawler-INAR,in Machine Learning and Cybernetics[J].2006 International Conference on, 2006:4527-4530.

[9] C LI, C DING, K SHEN.Quantifying the cost of context switch[J].in Proceedings of the 2007 workshop on Experimental computer science, 2007, p. 2.

[10]D KNUTH.Fundamental Algorithms: Addison-Wesley, 1997.

[11]F P MILLER, A F VANDOME,J MCBREWSTER.“Coroutine: Computer multitasking, Iterator, Fiber (computer science), Generator (computer science), Green threads, Lazy evaluation, Pipeline (Unix), Protothreads, Subroutine, Computer science,” 2009.

[12]E A LEE. The problem with threads[J].Computer, vol. 39, pp. 33-42, 2006.

[13]MELVIN E CONWAY.Design of a separable transition-diagram compiler[J].Communications of the ACM, 1963, 6(7):396-408.

[14]D EICHMANN, The RBSE spider-balancing effective search against web load[J].Computer Networks and ISDN Systems, 1994, 27(2): 308-316.

[15]周德懋,李舟军. 高性能网络爬虫: 研究综述[J].计算机科学, 2009, 36(8): 26-29 .

[16]李晓明,闫鸿飞,王继民. 搜索引擎:原理、技术与系统(2)[M].北京: 科学出版社, 2012.

[17]高克宁,柴桥子,张斌,等. 支持 Web 信息分类的高性能蜘蛛程序[J].小型微型计算机系统, 2006, 27(7): 1308-1312.

[18]肖明军,张巍,邹翔,等. 一种多策略联合信息抽取方法[J].小型微型计算机系统, 2005, 26(4):614-61

[19]陈杰. 主题搜索引擎中网络蜘蛛搜索策略研究[D].杭州:浙江大学, 2006.

[20]尹江,尹治本,黄洪.网络爬虫效率瓶颈的分析与解决方案[J].计算机应用, 2008, 28(5): 1114-1119.

[21]中国互联网络信息中心. 第27次中国互联网络发展状况统计报告[R]. 2011.

[7] HEYDON A,NAJORK M.Mercator: A scalable, extensible web crawler[J].World Wide Web, vol. 2, pp. 219-229, 1999.

[8] Y.-X. Ding, X.-L. Wang, L.-B. Lin, Q. Zhang, and Y.-H. Wu.The Design and Implementation of the Crawler-INAR,in Machine Learning and Cybernetics[J].2006 International Conference on, 2006:4527-4530.

[9] C LI, C DING, K SHEN.Quantifying the cost of context switch[J].in Proceedings of the 2007 workshop on Experimental computer science, 2007, p. 2.

[10]D KNUTH.Fundamental Algorithms: Addison-Wesley, 1997.

[11]F P MILLER, A F VANDOME,J MCBREWSTER.“Coroutine: Computer multitasking, Iterator, Fiber (computer science), Generator (computer science), Green threads, Lazy evaluation, Pipeline (Unix), Protothreads, Subroutine, Computer science,” 2009.

[12]E A LEE. The problem with threads[J].Computer, vol. 39, pp. 33-42, 2006.

[13]MELVIN E CONWAY.Design of a separable transition-diagram compiler[J].Communications of the ACM, 1963, 6(7):396-408.

[14]D EICHMANN, The RBSE spider-balancing effective search against web load[J].Computer Networks and ISDN Systems, 1994, 27(2): 308-316.

[15]周德懋,李舟军. 高性能网络爬虫: 研究综述[J].计算机科学, 2009, 36(8): 26-29 .

[16]李晓明,闫鸿飞,王继民. 搜索引擎:原理、技术与系统(2)[M].北京: 科学出版社, 2012.

[17]高克宁,柴桥子,张斌,等. 支持 Web 信息分类的高性能蜘蛛程序[J].小型微型计算机系统, 2006, 27(7): 1308-1312.

[18]肖明军,张巍,邹翔,等. 一种多策略联合信息抽取方法[J].小型微型计算机系统, 2005, 26(4):614-61

[19]陈杰. 主题搜索引擎中网络蜘蛛搜索策略研究[D].杭州:浙江大学, 2006.

[20]尹江,尹治本,黄洪.网络爬虫效率瓶颈的分析与解决方案[J].计算机应用, 2008, 28(5): 1114-1119.

[21]中国互联网络信息中心. 第27次中国互联网络发展状况统计报告[R]. 2011.

[7] HEYDON A,NAJORK M.Mercator: A scalable, extensible web crawler[J].World Wide Web, vol. 2, pp. 219-229, 1999.

[8] Y.-X. Ding, X.-L. Wang, L.-B. Lin, Q. Zhang, and Y.-H. Wu.The Design and Implementation of the Crawler-INAR,in Machine Learning and Cybernetics[J].2006 International Conference on, 2006:4527-4530.

[9] C LI, C DING, K SHEN.Quantifying the cost of context switch[J].in Proceedings of the 2007 workshop on Experimental computer science, 2007, p. 2.

[10]D KNUTH.Fundamental Algorithms: Addison-Wesley, 1997.

[11]F P MILLER, A F VANDOME,J MCBREWSTER.“Coroutine: Computer multitasking, Iterator, Fiber (computer science), Generator (computer science), Green threads, Lazy evaluation, Pipeline (Unix), Protothreads, Subroutine, Computer science,” 2009.

[12]E A LEE. The problem with threads[J].Computer, vol. 39, pp. 33-42, 2006.

[13]MELVIN E CONWAY.Design of a separable transition-diagram compiler[J].Communications of the ACM, 1963, 6(7):396-408.

[14]D EICHMANN, The RBSE spider-balancing effective search against web load[J].Computer Networks and ISDN Systems, 1994, 27(2): 308-316.

[15]周德懋,李舟军. 高性能网络爬虫: 研究综述[J].计算机科学, 2009, 36(8): 26-29 .

[16]李晓明,闫鸿飞,王继民. 搜索引擎:原理、技术与系统(2)[M].北京: 科学出版社, 2012.

[17]高克宁,柴桥子,张斌,等. 支持 Web 信息分类的高性能蜘蛛程序[J].小型微型计算机系统, 2006, 27(7): 1308-1312.

[18]肖明军,张巍,邹翔,等. 一种多策略联合信息抽取方法[J].小型微型计算机系统, 2005, 26(4):614-61

[19]陈杰. 主题搜索引擎中网络蜘蛛搜索策略研究[D].杭州:浙江大学, 2006.

[20]尹江,尹治本,黄洪.网络爬虫效率瓶颈的分析与解决方案[J].计算机应用, 2008, 28(5): 1114-1119.

[21]中国互联网络信息中心. 第27次中国互联网络发展状况统计报告[R]. 2011.

猜你喜欢

爬虫高性能分布式
居民分布式储能系统对电网削峰填谷效果分析
基于Python的网络爬虫和反爬虫技术研究
高性能混凝土不同配合比下的性能研究
Python反爬虫设计
基于Paxos的分布式一致性算法的实现与优化
高性能混凝土开裂成因及控制要点
基于Scrapy框架的分布式网络爬虫的研究与实现
谁抢走了低价机票
中国E级高性能计算机原型系统正式进入研制阶段
浪潮高性能计算用心良苦