分布式网络爬虫的设计与实现应用

1、摘要题目： 分布式网络爬虫的设计与实现应用摘要：随着互联网网络规模的爆炸性增长，相关的服务和信息量也随之快速增 长，集中式网络爬虫信息采集的速度已经无法满足快速获取大量数据的需求。 分布式网络爬虫由可并行获取资源的多个节点爬虫组成，它们在数据检索方 面表现优秀。因此，本文将根据风险平台的需求，设计出一个高效的分布式 网络爬虫。本文在对当前流行的分布式网络爬虫的相关技术进行了一定研究的基础 上，分析系统设计要点，结合代码介绍系统实现细节，并通过对比实验体现 本爬虫的效率，最后对全文进行总结，并提出展望。本文所研究设计的分布式网络爬虫系统，不仅提高了计算机信息采集的 速度，最大限度地利用了网络带宽

2、，而且能够适应更多类型的数据，加强了爬 虫的可扩展性。关键词：分布式网络爬虫；Bloom过滤器；搜索引擎第二章相关技术基础第二章相关技术基础2.1引言本章针对系统实现过程中使用的优秀的思想和技术的原理进行了较为详细 地介绍，为下文的系统设计说明作铺垫。本章的结构安排如下：第2节对Nutch 分布式搜索系统进行了介绍，了解分布式网络爬虫在搜索引擎中的作用和位置， 明确分布式网络爬虫需要实现的功能；第3节对增量式爬取策略进行了介绍，结 合爬行节点的运行逻辑解释增量式爬取策略；第4节的Bloom过滤器解决了增量 式爬取策略中的去重问题，应用于URL的增量过程中；第5节简单介绍了系统中 运用的“池”的

3、概念，从数据连接池和线程池两个方面进行了简单的介绍；第5 节对本章进行了小结。2.2 Nutch分布式搜索系统如今的互联网犹如浩瀚的海洋，想在互联网中搜寻需要的信息，就如大海捞 针，没有一定的工具几乎是无法实现的。因此网络搜索是互联网发展中一项必不 可少的功能，然而，现有Web搜索引擎的数目不增反降，其中缘由则是某些公司 为了谋取商业利益而垄断Web搜索市场，这对于互联网的长远发展和互联网用户 的利益是极其不利的。作为开放源代码的搜索引擎,Nutch的目标是让每个开发 者能很容易，同时花费很少的费用就可以配置世界一流的Web搜索引擎,尽自己 最大的努力为用户提供最好的搜索结果10oNutch是

4、Apache的一个开源搜索引擎项目，于2002年8月发布，而如今的 Nutch也已经从搜索引擎渐渐演化为了网络爬虫。为了能够完成最初的开发目标, Nutch必须能够做到每个月抓取几十亿的网页，并为这些网页维护一个索引，而 对这些索引文件能够执行每秒上千次的搜索，以最小的成本，提供高质量的搜索 结果11。Nutch作为一个开源的搜索引擎，具有很强的可扩展性，研究工作者可以在 Nutch的基础上，根据自己的研究需要，设计开发自己的搜索引擎，把搜索结果 以自己想要的方式呈现出来，因此，Nutch需要具备低耦合度和高可扩展性。第二章相关技术基础Nutch模块化的设计为用户提供了很多的便利。Nutch搜

5、索引擎具体可以分为三个主要的模块：采集模块，索引模块和搜索 模块。采集模块即是Nutch搜索引擎的爬虫模块，是本文所研究的分布式网络爬虫 所处的模块。采集模块的主要任务是通过初始URL,不断抓取获得新的URL,并 对这些信息进行相关的处理。CrawlDB还会生成一个待抓取的网页URL集合 Fetchlist,而Fetcher进程则会对抓取到的网页中相关的信息进行下载。 Fetchlist不断更新，则会下载到更多的网页，而从更多的网页中又会抓取到更 多新的网页URL加入Fetchlist,这样构成了一个循环过程，其“产生/抓取/更 新”的循环步骤一直进行下去12oNutch将网页中的相关链接抓取

6、下来后，为了提高搜索效率，可以提前建立 索引，索引模块完成的就是这样的工作。Nutch中的索引采用倒排索引，此索引 是建立在Lucene框架之上，因此采用倒排索引可以提供更为高效的搜索服务。查询模块则是为用户提供查询界面的，用户在该界面键入搜索请求，当它到 达搜索引擎的服务器时，查询模块就会通过索引模块中索引库的程序来进行处理, 检索完成之后，根据一定的排序算法，生成搜索结果，将其在Web页面中呈现给 使用的用户。Hadoop最开始是作为Apache Nutch的一*个网络搜索引擎的一个基础设施， 是一个稳定的且具有较好扩展性的架构。其主要设计思路和谷歌的Map/Reduce 以及分布式文件系

7、统一样13。其中的分布式文件系统HDFS不仅仅用于Nutch中 的存储，同时也是大型搜索系统中的应用框架，基于Hadoop分布式搜索引擎系 统的整体层次结构如图2-1所示14oNutch是优秀的开源搜索引擎，可以对海量的URL进行爬行与管理，但是其 中的爬虫是为搜索引擎而专门设计的，不适用于精准数据爬取，因此，Nutch运 行的过程中，会浪费很多的时间在不必要的计算上，即使对Nutch进行二次开发， 也会破坏Nutch的框架，失去原本的优势。而且Nutch依赖Hadoop运行，Hadoop 本身也会消耗很多的时间，如果集群机器数量较少，爬取速度反而不如单机爬虫 快。第二章相关技术基础图2-1基

8、于Hadoop分布式搜索引擎系统的整体层次结构本文所研究的分布式网络爬虫从实际项目背景出发，在保证爬行效率的基础 上，还强化系统可扩展性，使其能够适应多种类型数据。在对Nutch搜索引擎的 结构有了一定的研究后，本文所研究的分布式网络爬虫的主要工作变得更加明晰。 结合Nutch的模块分配，分布式爬虫在解析初始URL集合的基础上，不断深入爬 取网页中的链接，下载网页信息，并对相关的信息进行处理和保存。建立索引、 提供查询等功能会在后面的模块中完成，爬虫部分不需涉及。2.3增量式爬取策略在对Nutch分布式搜索引擎有所了解后，我们明确了分布式网络爬虫的主要 功能，从这一部分开始将深入介绍一下分布式

9、网络爬虫中所使用的关键技术，首 先从增量式爬取方式开始说明。在互联网中，爬虫主要功能就是将需要的网页数据从网页上下载下来，并将 数据信息提供给搜索引擎，便于搜索引擎的搜索。通常，我们所说的网页数据不 仅包含了大量的文字及图片数据，还包括很多网页链接。网络爬虫就是利用这些 链接来爬取更多的网页，从更多的网页中获取更多的链接，这一数据采集的过程 就和爬虫或蜘蛛在网上爬行一样，所以我们将其称为网络爬虫。我们在使用网络爬虫爬取网页时，一般都会选择链接数比较多的网站作为种 子URL,在网络爬虫系统中被称为初始URL,通过初始URL集合开始在互联网中 进行爬行。初始URL中的链接数越多，就可以爬取到越多新

10、的网页链接。网络爬第二章相关技术基础虫一般会根据一定遍历算法遍历网页，通常包括广度优先算法和深度优先算法。 如果使用深度优先搜索算法，不断地深入搜索，在网络结构复杂的情况下，就很 可能导致爬虫陷入网站的内部，无法获取其他网站的信息，所以更多的时候会使 用广度优先搜索算法。网络爬虫的工作策略一般可以分为累积式抓取和增量式抓取两种。累积式抓 取是指从某一个时间点开始，通过遍历的方式抓取系统所能允许存储和处理的所 有网页。在理想的软硬件环境下，经过足够的运行时间，累积式抓取的策略可以 保证抓取到相当规模的网页集合。但由于Web数据的动态特性，集合中网页的被 抓取时间点是不同的，页面被更新的情况也不同

11、，因此累积式抓取到的网页集合 事实上并无法与真实环境中的网络数据保持一致。增量式抓取是指在具有一定量 规模的网络页面集合的基础上，采用更新数据的方式选取己有集合中的过时网页 进行抓取，以保证所抓取到的数据与真实网络数据足够接近。进行增量式抓取的 前提是，系统已经抓去了足够数量的网络页面，并具有这些页面被抓取的时间信 ，息、O本文所研究的分布式网络爬虫采用增量式爬取的方式，网络爬虫在爬行网页 的过程中，先把初始URL推送至下载队列首部，然后依次出队列，下载链接对应 网页信息，获取的新链接，判断该链接是否己经爬取或过时，如果已爬取且不过 时，则不再爬取，若未爬取过或已过时，则推进下载队列中，如此循

12、环，直到下 载队列为空。2.4 Bloom过滤器在互联网的日常应用中，我们可以发现，想要进入某一网页，可以从众多不 同的网站上点击链接，该网页的链接会多次出现在不同网页中。当我们用爬虫爬 取网页时，必定也会爬取到很多相同的网页链接，如果对这些网页都进行下载并 继续爬取，又会产生更多相同的网页链接，这样得到的爬虫会受到巨大的影响, 效率大大降低。因此，我们需要想办法把这些重复的网页URL去除。针对数据量比较小的情况，我们可以将访问过的URL保存到数据库中，每爬 取一个新的URL,就与数据库中URL进行对比，丢弃重复的URLo也可以使用 HashSet将访问过的URL保存起来，同样对比去重。但是随

13、着URL的增多，占用第二章相关技术基础的内存会越来越多。为了解决内存的问题，我们可以使用Bit-Map方法，将每一 个链接地址通过一个哈希函数映射到BitSet中的某一位，这样内存的压力是相 对较少了，但是只是使用单一的哈希函数发生冲突的概率还是太高了，若想要把 冲突发生的概率降低到1%,就要将BitSet的长度设置为链接地址个数的100倍, 这样就又得不偿失了。因此，为了解决上面的问题，本文的分布式网络爬虫需要对URL进行去重。 在新的URL加入爬行等待序列前，需要将其与己爬行的URL进行对比。本文采用 一种较为高效的过滤器一一Bloom过滤器，在URL的增量过程中，对URL进行去 重。Bl

14、oom过滤器于1970年提出，是一种应用于快速判断某个元素是否输入集 合的快速查找算法。这种算法采用了多哈希函数映射的方式，运算结果适用于不 完全精确的场合15oBloom过滤器在BitSet的基础上进行了改进，为了降低冲突的概率，使用了 多个哈希函数。在应用过滤器前，我们需要设置一个m位的BitSet,每一位都 初始化为0,然后选择k个不同的哈希函数，用第i个哈希函数对字符串str进 行映射，其结果记为h(i,str)。当我们爬取到一个新的URL时，将该URL的信息包装成一个字符串的形式, 将该字符串加入到BitSet中。对于字符串str,分别计算h(l,str), h (2, str),

15、h(k,str)位设为 1。如图 2-2 所示：bi b2 bj b4 bi b6 bz bs b9 bio bn bia bn bu bis bi60 2-2 Bloom Filter加入字符串过程如图2-2所示，字符串str就成功地映射为BitSet的k个二进制位了，大 大降低了内存的压力。字符串能够被成功加入后，若有新的字符串出现时，我们 就需要对这个字符串进行检验，是否与之前的字符串重复，是否应该加入待爬 URL列表。对于新的字符串newstr,我们需要将newstr代入MD5哈希算法中，分别计10第二章相关技术基础算 h (1, newstr), h (2, newstr),., h

16、 (k, newstr),然 后检查 BitSet 的第 h (1, newstr), h (2, newstr),., h (k, newstr)位是否为 1,若其中任何一位不为 b则说明这个新的字符串一定没有被记录过，若全部位都是1,则可以暂且认为 字符串存在。不过，我们也不能说这个字符串一定存在，因为有时也会出现该字 符串的所有位刚好都被其他字符串映射过的现象，这种现象也被称为false positiveo加入过滤器的字符串最好就不要再删除了，无论哪一个字符串被删除都有可 能对结果带来影响。如果确实需要删除字符串时，可以使用Counting Bloom Filter (CBF),这是一种

17、基本Bloom Filter的变体，它将位改成一个计数器， 通过计数器的加减实现字符串的删除。过滤器的性能很大程度上取决于其中的哈希算法的选择，一个优秀的哈希函 数要能近似等概率的将链接地址映射到各个位。本文在使用Bloom过滤器时，选 择MD5哈希函数，然后选择k个不同的参数，从而针对每个字符串可以计算出k 个哈希结果，映射BitSeto根据本文需求，k值设置为8, BitSet设为URL总数 n的20倍，false positive的值降低为0. 00014,基本符合本项目分布式网络 爬虫的需要了。2.5连接池与线程池本分布式网络爬虫由一个中央爬虫和多个节点爬虫组成，每个节点爬虫中又 使用

18、多线程的方式，同时开启5个线程对网络数据进行爬取。这么多的线程同时 抓取网络中的数据，得到的数据必然是庞大的，如果要将这些数据全都加入数据 库，对数据库会产生极大的压力。因此，研究者提出了 “池”的概念，具体的解决方案是当多个应用程序向数 据库提出请求时，为这些应用程序同时建立足够多个数据库连接，并且让这些连 接形成一个连接池，这样应用程序就可以对连接池中的连接进行动态的申请、使 用和释放。当应用并发请求数多于连接池中连接数时，应用程序应该排队等待 16。本文所使用的数据库是MySQL,采用JDBC数据库连接池，通过Connection 函数从连接池中获取connection,对数据库的进行操

19、作，不需要使用时，用close11第二章相关技术基础函数将connection放回数据库连接池，当connection不足时，数据库连接池也 会自动增加connection个数。获取数据库连接的代码如图2-3所示：ComboPooledDataSource dataSomce = DBCoimection.getIiistaiice();Coimection comi = data S oiuce. getC oimection():图2-3获取数据库连接同样，由于多线程的形式，在爬虫节点采用线程池的方式管理线程。线程池 的作用就是限制系统中执行线程的数量，当有一个新的任务需要完成时，若此时

20、线程池处于空闲状态，则调用线程池中等待的线程开始运行；若线程池处于部分 运作的状态，则完成队列中的第一个任务；若线程池处于满负荷的状态，该任务 就先进入等待队列。这样，不仅可以最大限度的重复利用工作线程，还可以防止 占用过多的内存，造成服务器过高负载而停机。2.6本章小结这一章节主要介绍了本文系统相关的技术背景，通过对系统中需要运用到的 技术及背景进行了比较详细的介绍，借鉴当前优秀的爬虫系统Nutch的设计经 验，为之后的系统设计与实现打下了良好的基础。本章介绍的内容包括Nutch分布式搜索系统的基本知识、增量式爬取策略、 Bloom过滤器、数据库连接池及线程池的相关知识，从多个角度由浅入深地

21、介绍 了分布式网络爬虫的背景及原理，为下文的系统框架的搭建提供了很好的经验, 为整个项目的研究打下了良好的理论基础。12第三章爬虫逻辑设计第三章爬虫逻辑设计3.1引言本章对分布式网络爬虫的设计展开研究，在实现系统前，对系统的整体框架 及其中的逻辑控制进行详细的设计，意义在于搭建较为合理的爬行框架，从整体 上提高爬虫的效率，也为后文的系统详细设计做好铺垫。本章的结构安排如下: 第2节阐述了本系统采用主从式爬行结构和基于TCP/IP的Socket通信的原因; 第3节从中心节点和爬行节点两种节点的角度分别设计逻辑运行策略，阐述运行 过程并解释设计缘由；第4节介绍了系统在不同状况下发生异常时的处理方式

22、; 第5节对本章进行了小结。3.2整体结构分布式网络爬虫主要分为两种系统架构，一个是主从式，整个系统中包含两 种类型的节点，分别为中心节点和爬行节点。中心节点主要负责对爬行节点的管 理和对爬行任务调度，爬行节点则负责抓取网络信息，为中心节点提供新的URL； 另一种是并列式，在这个系统中，所有的节点功能相似，不仅要爬取网络信息, 获取新的链接，而且每个节点都维护着一个其他节点地址的列表，当爬取到任务 时，要通过这个列表中将爬行任务分配给其他合适的爬行节点17o本文分布式网络爬虫运行的网络环境使用校园网络，网速并不是特别理想, 因此网络带宽是极其重要的资源，直接影响到爬虫系统的运行效率，并列式网络

23、 爬虫需要维护其他节点地址的列表，当节点产生或断开时，将会产生大量的系统 损耗，降低了网络带宽的利用率，但是主从式网络爬虫系统与之不同，它的任务 分配集中在中心节点上，中心节点可以随时根据爬行节点的爬行情况进行爬行任 务的分配，避免了并列式网络爬虫各个爬行节点之间的任务不均现象。因此，本文选择使用主从式系统架构进行总体设计，其结构如图3-1所示:13第三章爬虫逻辑设计本文使用Java语言编写，通过Socket通信方式进行中央节点与爬虫节点的 联系。另外，TCP协议是一种面向连接的可靠传输协议，UDP是面向非连接的， 考虑到本系统对信息传输的要求，本文选择基于TCP/IP的Socket通信建立可

24、靠 的传输链接18。在本文中，中央节点即Socket通信中的服务器端的角色，爬行节点即Socket 通信中的客户端的角色，由于一个中央节点对应多个爬行节点，因此我们还要使 用多线程的机制，中心节点通过多线程控制多个爬行节点，爬行节点通过多线程 控制多个爬虫并行爬取网络。3.3逻辑控制中心节点的线程主要负责管理爬虫节点，可以随时查询爬虫的状态，确认爬 虫完成的任务以及管理爬行出错的URL。因此，对于中心节点来说，主要分为三 个线程控制任务：（1）反馈确认当爬虫节点完成中心节点安排的URL任务，返回完成结果时，如果中心节点 只是将URL列表中完成的部分删除，而不返回爬虫节点任何信息时，爬虫节点就

25、无法确定中心节点是否己经收到确定。假如爬虫节点返回完成结果时，传输出现 错误，中心节点并没有收到确认，而爬虫节点已经将该部分URL删除，那么超出 一定时间后，中心节点就会误以为这部分URL没有完成爬取任务，加入出错URL 的队列，浪费资源，降低爬取效率。因此，中心节点在收到爬虫节点发过来的完成任务的URL信息时，需要对完 成的内容进行确认，不仅要从中心节点的待确认URL列表中将该部分URL出队, 而且要返回给爬虫节点一个确认信息，供爬虫节点操作。14第三章爬虫逻辑设计轮询检测在爬虫运行过程中，爬虫节点可能因为多种原因发生异常，与中心节点断开 连接，因此，中心节点需要随时了解爬虫节点的运行状态，

26、通过遍历的方式，询 问各个爬虫节点的状况，当检测到某个爬虫节点出现故障时，应停止对其发送任 务，完善后续任务。URL丢弃首先将ErrorURL在所有没有被爬取过的爬虫节点上进行爬取，如果都没有 爬取到结果，就说明是这个URL有问题，应将其丢弃。在这个过程中，我们也要 注意线程的控制，不能为了爬取出错URL而影响正常URL的爬取，因此，应设置 线程等待，控制处理出错URL的速度。与中心节点不同，对于爬虫节点来说，它 的任务主要是完成爬行任务，并将爬行结果反馈给中心节点。本文所研究爬虫系统采用增量式爬取策略，爬虫节点运行逻辑如图3-2所示:图3-2增量式爬取策略运行逻辑15英文摘要THESIS:

27、Design and Application of Distributed Web CrawlerABSTRACT:With the scope of Internet growing explosively, related service and information is exploding as well. Centralized network crawlers cannot meet the requirement of mass data in a short time. Distributed web crawlers are made up of several crawl

28、er nodes which can get data synchronously. They have excellent performance on data retrieval. Therefore, we design an efficient distributed web crawler according to the need of the risk platform.This paper does some research on popular distributed web crawler technologies. It analyzes design points

29、of the system and introduces details by codes. Then we carry out a comparative experiment to reflect efficiency of the system. At last, we conclude the paper and put forward prospects.This system not only speeds up collecting information and makes the most of the network, but also improves crawlers9

30、 adaptation to more kinds of data and enhances its extensibility.KEYWORDS: Distributed Web Crawler; Bloom Filter; Search Engine第三章爬虫逻辑设计由图3-2可以看出，该分布式网络爬虫在抓取到新的URL后，并不是对于所 有爬取到的URL都进行深入的爬行，而是先对该URL进行两次判断，只要该URL 在最近一段时间内被爬取过，就不必再次进行爬行，如果该URL未被爬取过或者 已经网页已经过时，就将该URL推入下载队列，再次进行爬取，这样的做法既可 以保证网页的新鲜度，又可以有效

31、地避免爬行资源的浪费。其中，在判断新URL 是否已爬取时，我们采用第二章中介绍的Bloom过滤器，将爬取到的新的URL映 射为多维空间中的一个点，若点与原空间中的一个点重合，那么就可以认为该 URL已经被爬取过，进入下一个判断流程。这样的过滤方法快速有效，避免URL 的重复爬取。3.4异常处理该分布式爬虫系统采用主从式架构，将节点分为控制节点和爬虫节点，因此 在考虑异常处理时也要分别针对控制节点和爬虫节点进行崩溃处理。控制节点控制节点位于系统的中心，因此控制节点的崩溃处理十分重要。如果无法正 确处理控制节点崩溃的状况，有可能导致之前所取得的结果全都白费，甚至整个 系统停顿，无法继续支持。当面临

32、控制节点发生异常时，我们需要做好日志恢复 的工作。这里所说的日志恢复，不仅包括控制节点的日志恢复，还包括爬虫节点 的日志恢复。当系统重新恢复正常时，存储的日志需要能够提供已爬取和未爬取 URL的信息。爬虫节点爬虫节点的崩溃有两种可能的原因：一是控制节点的崩溃或整个系统的崩溃, 还有一个是该爬虫的崩溃。当控制节点或整个系统崩溃时，爬虫节点应该将未爬 取的URL在本地完整保存；当只是该爬虫发生崩溃时，为了保证爬行结果的完整 性，爬虫节点应该将未爬取的URL回送给控制节点，由控制节点分配给其他正常 的爬虫对这些URL继续进行爬取。3.5本章小结本章根据研究的需求分析分布式爬虫的逻辑设计要点。首先，从

33、整体结构上16第三章爬虫逻辑设计简单介绍了该分布式爬虫，选择了主从式的架构进行研究，采取基于TCP/IP的 Socket通信建立可靠的通信连接。然后，根据分布式网络爬虫的功能，分别介绍 了中心节点和爬行节点在逻辑上的运行方式。接着，具体地介绍了在不同情况下 系统出现异常时的处理方式。最后，对本章进行了小结。总的来说，本章对分布式网络爬虫的逻辑设计进行了详细的分析，选择合适 的运行方式，从整体上提高了爬虫的效率，对实验的详细设计也带来了极大的便 利，为本文的完成奠定了坚实的基础，是系统高效实现的前提。17第四章系统实现第四章系统实现4.1引言本章在第三章逻辑设计的基础上，对系统进行了更为详细的设

34、计，从系统实 现的角度对系统的细节进行介绍，在系统代码编写前，统一变量、对象，有助于 模块化地实现分布式网络爬虫系统。本章的结构安排如下：第2节介绍了与本系 统相关性最高的四种URL对象，从数据结构的角度，分析和解释URL的在系统运 行时的流动过程；第3节对通信过程中使用的报文进行了简单的介绍，分析各个 域的设计意义；第4节以爬虫节点向中心节点发送爬取到的URL的任务时的报文 解析过程为例解释了报文的传输过程；第5节对本章进行了小结。4.2数据结构根据项目需要，本项目共涉及四种URL相关的对象，分别为RawData, InterfaceURL, PackagedURL和ErrorURLo下面依

35、次对这四类对象进行讲解：RawData这个对象是在最终网页页面上抓取到URL时创建的，主要属性如表4-1：表4T RawData属性表属性名idlistldcategorysiteNamechannelurlName类型intintStringStringStringString属性名(接上)urltitlehrefTexttextinputTimescore接上StringStringStringStringStrinsStrina其中，id是key值，唯一确定RawData, listld为取到该链接的网页编号, siteName为取到该链接的网站的地址，url即为链接地址，title和h

36、refText主 要记录该链接的标题内容，inputTime为抓取到该URL的时间。18第四章系统实现（2）InterfaceURLInterfaceURL是原始URL的抽象类，根据URL类型的不同，又分为两种不同 的URL形式，分别命名为URLl_Impl和URL2_ImploURLl_Impl为第一种类别的原始URL,是三级爬取中的第一级，其主要属性 如表4-2：表4-2 URLLImpl属性表其中大部分跟RawData的相同的属性不再赘述，channel可以记录代理或网 关的服务器相关信息，由于某些网页可以翻页，因此pageUrl此处也需要记录,属性idcategorysiteNamec

37、hannelurlNameintStringS trineStringString属性名（接上）urltypecontentkwfrequencyscore（接上）StrinaStringStringintString属性名（接上）remarkisTo VisitinputTimeupdateTimepageUrl缠（接上）StrinaJintStrinaStringString属性名（接上）hrefText超（接上）S trineJURL2_Impl是第二种类别的原始URL,是三级爬取的第二级，其主要如表4-3所示：表4-3 URL2_Impl属性表(3) PackagedURL属性名idl

38、istldcategorysourcesiteNamechannelintStringStrinaStringStringString属性g（接上）urlNameurlhrefTextinputTimepubDateStringStrinaStrinsStringString上面介绍了两种基本的URL类型，接下来的两种类型都是在前两种的基础上19第四章系统实现形成的。PackagedURL在原始URL InterfaceURL _b包装了一些信息，更方便 程序快速解析，是在该系统中最主要的URL对象，在组织URL队列时，采用的就 是PackagedURL类型。其主要属性如表4-4：表4-4 P

39、ackaged属性表(4) ErrorURL字段名URLNumberclass_typetypeurlfilterintintintInterfaceURLboolean含义URL#,唯一URL所属类别URL用遗中类原始URL是否需要过滤当URL出错，不是正确的链接地址或者多次尝试后仍无法获取链接网页时, 需要将该URL加入出错URL的队列当中，因此需要对出错URL设计一个类型，主 要就是在URLl_Impl类型的process_url字段上，再添加一个包含Error信息的 字段。4.3报文设计本文使用基于TCP的Socket通信，各节点间采用主从式通信，因此在设计 传输报文时，最重要的设计原

40、则就是用最少的数据包发送最多的URL信息，降低 冗余度，从而达到提高爬虫爬取效率的最终目的。本文的报文设计主要分为四个部分，如表4-5所示：表4-5传输报文设计表typefieldsPackaged_urlRunning_NumberintHashtablelnteger/ IsoValuePackagedURLint报文对象信息报文对象域信息报文传输的URL，报文所属流水号 类型不传输URL时为NULLtypetype为报文对象对应的信息类型，各种类型对应不同的任务，具体对应的列 表如表46所不:20第四章系统实现表4-6报文对象对应信息类型表0 x100启动爬虫节点命令0 x110响应中心

41、节点命令0 x120暂停爬虫节点命令0 x130响应中心节点命令0 x140唤醒爬虫节点命令0 x150响应中心节点命令0 x160停止爬虫节点命令0 x170响应中心节点命令0 x180中心节点命令爬虫节点建立连接命令0 x190爬虫节点创建连接， 返回结果0 x200查询爬虫节点URL数量命令0 x210爬虫节点返回URL 数量命令0 x300爬虫节点返回已爬取URL信息0 x310响应爬虫节点命令0 x400爬虫节点申请URL命令0 x410将URL打包返回给爬虫节点0 x500爬虫节点向中心节点发送爬取到的URL0 x510响应爬虫节点命令0 x520爬虫节点向中心节点发送未爬取的UR

42、L(爬虫节点要退出时)0 x530响应爬虫节点命令0 x540爬虫节点向中心节点发送爬取出错的URL0 x550响应爬虫节点命令0 x600中心节点发送过来爬取出错的URL0 x610响应中心节点命令fieldsfields字段存储报文对象所有包含的域信息，域信息中又包含域的编号id, 域的名称name,域的数据类型type和域数据的长度length共4个重要的信息。 其中，域的数据类型type可以满足Integer类型、String类型和Date类型的 数据传输。Packagedurl当该报文是用于传输URL时，保存传输的URL,当不传输URL时，为NULL。Running_Number该字

43、段为报文所属流水号，为唯一确定报文而设置。4.4报文传输根据报文的type类型，利用switch语句，对不同情形进行不同的任务。对 爬虫节点的启动、暂停、唤醒和停止操作是否成功，新建socket连接是否成功， 查询URL信息等任务，主要通过fields对象中的具体字段信息可以判断出来。21第四章系统实现在该系统中采用UnPackage_Message函数对报文进行解析，使用byte数组 获取报文中的首部，并根据首部的内容判断数据的类型，再进一步创建相应的对 象解析和存储报文中的内容。由于报文传输的状况较多，此处以爬虫节点向中心节点发送爬取到的URL的 任务时的报文打包发送的过程为例，讲解报文发

44、送的流程。首先，从爬取到的URL 的List中获取第一个需要传输的URL,将它的主要信息放入一个报文类型的 message_temp中，并根据PackagedURL中的type,确定URL的类型，对应类型 的数量加1,写入报文中，然后，将所有信息包括message_temp放入将会返回 给中心节点的message_return报文中，通过Socket发送出去。代码如图4-7：IsoMessage message = messages.get(O);List list = new ArrayList();fbr(IsoMessage message_temp : messages)int cla

45、ss_type = message_temp. getPackagedURLQ -getClass_typeQ；int type = messagetemp. getPackagedURL 0 - getTypeQ ；Variable. getlnstance(). add_spider_queueQ;switch(message_temp.getPackagedURLO-getType().Hashtable fields_retum = new Hashtable1A7O1 17 7HnnQA Qn2 =znTT5FU J暂停 唤醒 停止操作结果启动操作成功中心节点控制器保存过滤器停止服务

46、配置文件 配置文件发送报文基本信息接收报文基本信息系统当前状态配文件工作日志显示IE置文件配置文件IE置文件配置文件图5-1运行过程中界面截图此截图为运行一台中央节点和六台爬行节点一分钟左右时的情况，从左边一 列可以看出六个爬行节点均与中央节点相连，爬虫端口号也列举出来，右边一列 主要展示当前爬取URL的状态，数据源属于第一类URL,任务总量为2000,此时 爬取到的第二类URL总量为1858个，第三类URL总量为12896个。对于中心节点的爬取结果做了部分的截图，图5-2为日志记录结果，图5-3为数据库最终结果:2015-05-22 22:12:09 INFO INFO INFO INFO

47、INFO INFO INFO INFO INFO INFO INFO INFO INFO INFO INFO INFO INFO INFO INFO INFO INFO INFO INFO INFO INFO INFO INFO INFO INFO INFODisplayVariable DisplayVariable DisplayVariable DisplayVariable DisplayVariable DisplayVariable DisplayVariable DisplayVariable DisplayVariable DisplayVariable DisplayVari

48、able DisplayVariable DisplayVariable DisplayVariable DisplayVariable DisplayVariable DisplayVariable DisplayVariable DisplayVariable DisplayVariable DisplayVariable DisplayVariable DisplayVariable DisplayVariable DisplayVariable DisplayVariable DisplayVariable DisplayVariable DisplayVariable Display

49、Variable318319321339340341342343344345346347348349350351352353354355356357358359360362366370373374:2015-05-22 21:46:122015-05-22 22:12:09:2015-05-22 22:12:092015-05-22 22:12:09:00:25:562015-05-22 22:12:09任务数量一级URL数量:2000 2015-05-22 22:12:09 任务数量二级URL数量：1942 2015-05-22 22:12:09 任务数量三级眼数量:50595 2015-0

50、5-22 22:12:09 2015-05-22 22:12:09 2015-05-22 2015-05-22 2015-05-22 2015-05-22 2015-05-22 _魂唯毂童:0 故一二级激董： 争礴认无戏、赡咨甲宣URL毂量三级URL款量:0-已确认无戏、圭出骨URL微量一级URL戮量:71 -已懑赤魂、iiifURLg量二级URL毂量:182 -己硬认无外肥去出寅URL数量三级URL数量：2930 -过遮URL戎量一级URL数量：0 -过喙URL数0二级URL数量:0mil ft2015-05-22 22:12:09兀成URL处一-二级URL处理-正确！ ！ ！-三级URL处

51、理-正确！ ！ ！。塔 5 J三级皿数量:374套袈量一班IM遂量：1929 g毂量二级URI燃量：1760 务数量三级URL数量:4392422:12:0922:12:0922:12:0922:12:0922:12:092015-05-22 : 2015-05-22 : 2015-05-22 : 2015-05-22 : 2015-05-22 : 2015-05-22 : 2015-05-22 22:12:09 2015-05-22 22:12:09 2015-05-22 22:12:092015-05-22 22:12:092015-05-22 22:12:09 2015-05-22 22

52、:12:09 2015-05-22 22:12:09 2015-05-22 22:12:09 2015-05-22 22:12:0922:12:0922:12:0922:12:0922:12:0922:12:0922:12:092015-05-22 22:12:09图5-2日志记录结果24第五章对比实验IDUSTIDCM. y SOURCE SITENAMECHA.URLN. URLTITLEHERFTEXTTEXTINPUTTIME1Taikor000021证券市场tl周刊.娥埋公开ft息理性选股植埋公开值息.!DOCTYPE h.2015-05-23 1.2Taikor000021证券市场

53、红周刊5/震荡模式已开忘选时迭震荡模式己开!DOCTYPE h.2015-05-23 1.3Taikor000021证券市场H周刊.强势蒋中或有秘跌反堂势藩中或有!DOCTYPE h.2015-05-23 1.4Taikor000021证券市场0周刊.浅谈卧底金阳和的能源浅淡卧底金阳和 dDOCTYPE h.2015-05-23 1.5TaikortXX)021证券市场红周刊.四月核电花开五月物流四月梭龟花开. !DOCTYPE h.2015-05-23 1.6Taikor000021证券市场就周刊.上证指盘整上证指数短期面“-!DOCTYPE h.2015-05-23 1.7Taikor00

54、0021证券市场处周刊.大盘送入强汇聚压力凶大盘进入强汇聚“-!DOCTYPE h.2015-05-23 1.87aikor000021证券市场红周刊.减少买入随时盘退-红减少买入萌时!DOCTYPE h.2015-05-23 1.9Taikor000021证券市场周刊.遇防风险关注军工就酒防风险关注!DOCTYPE h.2015-05-23 1.10Taikor000021证券市场红周刊.欲携故纵锁定中国宝欲擒故纵硕定 !DOCTYPE h.2015-05-23 1.11Taikor000021证券市场SI周刊.享受牛市的狂欢-红学室享受牛市的狂玖 !DOCTYPE h.2015-05-23

55、 1.12Taikor000021证券市场U周刊.大女震炫加大关注央企大盘质烙加大.!DOCTYPE h.2015-05-23 1.13Taikor000021证券市场红周刊.超预JT个股投责机会超ffiJT个股投DOCTYPE h.2015-05-23 1.14Taikor000021证券市场U周刊.上证指数突破压力位-红上证指数突破压dDOCTYPE h.2015-05-23 1.15Taikor000021证券市场H罔刊.迎接牛市中的调整-灯学迎接牛市中的演整!DOCTYPE h.2015-05-23 1.16Taikor000021证券市场红周刊.httpy/news. /15/.大盘

56、震荡挖掘新股-红大疙掘!DOCTYPE h.2015-05-23 1.17Taikor000021/券市场*1罔刊.石念吸引力火州石埔徽念吸引!DOCTYPE h.2015-05-23 1.18Taikor000021证券市场周刊.大fi|8j4176点一线雄续大盘向4176点!DOCTYPE h.2015-05-23 1.19Taikor000021证券市场红周刊 com/15/.呈价关系中看学星价关系中毒趋始!DOCTYPE h.2015-05-23 1.20Taikor000021证券市场口周刊.一带一防风险-一带一路”防风-!DOCTYPE h.2015-05-23 1.21Taiko

57、r000021证券市场灯周刊.从安全角度选梭电股-红从安全角度选- !DOCTYPE h.2015-05-23 1.22Taikor000021证券市场红周刊.上证指敷上涨日标-红学上ii指敷上涨日标!DOCTYPE h.2015-05-23 1.23Taikor000021泣券市场周刊.创业板耳跌前有信号!创业板$跌前有“-!DOCTYPE h.2015-05-23 1.24Taikor000021证券市场U周刊.大盘掌升到月线3663点大盘馨升到月 !DOCTYPE h.2015-05-23 1.25Taikor000021说券市场0周刊.K马在璃定性中飞奔-!熙马在确定性中 !DOCTY

58、PE h.2015-05-23 1.26Taikor000021证券市场就周刊.点名”事件后的思考及“点名事件后的 !DOCTYPE h.2015-05-23 1.27Taikor000021该券市场灯周刊.逢高H持待回调顺“风逢高减持待回 !DOCTYPE h.2015-05-23 1.28TaikortXXX)21证券市场红蜀刊.指并非点痣板块指数上涨并非!DOCTYPE h.2015-05-23 1.29Taikor000021证券市场0周刊.大盘重心上扬个股机会大盘鱼心上扬.!DOCTYPE h.2015-05-23 1.307aikor000021证券市场U周刊.逢防冲高冏落转入枳极

59、逢防冲MB*.!DOCTYPE h.2015-05-23 1.31niknrnnnn?i讶果市场打HI利httn7/nRm hnnazhniiknn cnm/15/卜济指g佥礴氏 Internet Archive Crawler 以及 Mercator5o 这些 爬虫都采用了分布式爬虫，分布式技术使得搜索引擎能够最快的搜索到大量网页。早期Google Crawler分布式爬虫采用主从式架构，主要由一个中心节点和 三个负责网页爬行的设备构成，三台设备之间不直接相连，但分别与中心节点进 行通讯6。中央主机负责从文件中将URL读取出来，并把URL发送给多个分设 备的Crawler进程。Crawler

60、进程会采用异步I/O的方式从三百多个互联网网站 中获取搜索的数据，并将页面进行压缩存盘。之后再将URL从HTML页面中提取 出来，并放置在页面存储以外的另一个磁盘文件中，Resolver进程会将存放在2第一章绪论这一磁盘中的文件读取出来，将相对链接转变为绝对链接，继而提供给主机。这 种做法确实可以提高爬行速度，但是缺陷也十分明显，若是中央主机出现故障, 那么整个系统都会受到影响，并且系统存在瓶颈，即中央主机用于分发URL的模 块。Internet Archive诞生于1997年，它采用了多线程以及异步I/O的技术， 每个爬虫进程启动64个爬行站点同时爬行，每个爬行站点在爬行过程中维护一 个爬行