CN105991699A - 一种互联网爬虫的分布式下载系统 - Google Patents

Abstract

本发明提供了一种互联网爬虫的分布式下载系统，该系统包括中心服务器、客户端、下载服务器和运用事件触发模型的DNS服务器集群。该系统能够为搜索引擎的爬虫提供高效、均衡的下载服务。

Description

一种互联网爬虫的分布式下载系统

技术领域

本发明涉及一种互联网领域的系统，具体讲涉及一种互联网爬虫的分布式下载系统。

背景技术

随着互联网的飞速发展，互联网的数据越来越庞大，根据中国互联网信息中心2013年中国搜索引擎市场研究报告，目前中国注册的网站数为320万，域名数1844万，网页数为1500亿，；截止2014年4月14日，全球总的域名已经达到136,285,365，其中美国以81,136,981个域名居首位，中国拥有7,907,696个域名，位居第2。

搜索引擎作为获取未知信息的主要方式，搜索引擎的爬虫如何下载庞大的数据就是一个很重要的问题。传统的单机下载模式，已经无法很好的完成海量数据的下载任务，如何建立一个健壮的，高效的分布式下载系统，更显得尤为重要。在实际情况之中，还有如下三个主要的问题：

1、分布式下载系统部署在机房时，由于机房自身的带宽限制或者服务限制产生的问题。比如，下载机器还需提供其它的网络服务，或整个机房还有其它的网络服务，若下载系统全部占用下行的带宽，会对集群的其它服务产生影响，造成这些服务访问不正常；或，一个下载系统有可能为多个其它系统提供下载服务，有的系统需要控制对对方网站的下载压力，有的系统不能占据太多的下载带宽。因此，如何有效并且简单的控制整个下载系统的下载带宽和均匀分配各个业务系统的下载请求到各个下载机器之上，也是十分必要和有实际意义的。

2、传统的域名解析方法为通过操作系统自带的gethostbyname底层c函数来进行域名解析，但由于该函数为同步函数，当一个线程在等待域名解析时，其它线程调用此函数也将全被阻塞，因此，即使使用多线程的进行下载，在进行域名解析调用该函数，仍是全局阻塞，从而，当遇到大量的域名解析请求时，域名解析成为整个下载系统的瓶颈。

虽然可以在各个下载程序内缓存部分DNS解析的结果，在下一次同域名解析时直接从缓存中获取，但此类方案也存在缺点。一、每一个下载端都需存储一份数据；二、域名总数十分庞大，全球已有1.3亿，其中还包括已经失效或故意作弊的域名，实际情况远远大于1.3亿；另外，域名解析支持通配解析，比如，*.qzone.qq.com，*可为任何QQ号码，它们一般指向同一个IP，但DNS解析过程无法得知这一条解析规则，也无法存储这一条规则，这条规则是对方DNS解析服务器的解析规则，因此，只能针对于每一个QQ号码的域名，存储一个键值对，即域名/IP对，那么仅仅这一条通配符规则所产生的域名就是海量的，从而，在每一个下载程序内部缓存全部的DNS解析结果，是不可行的。由此可见，DNS解析是广域网爬虫一个技术难点和关键点。

3、由于互联网各个服务器的位置和服务器带宽的能力的大小，在进行下载网页时，I/O等待造成的URL的延时的不同，也会影响整个系统的下载速度和能力，而传统解决IO等待的方案就是多线程模型，即各个线程完成不同的下载任务，互不影响，但使用多线程模型的缺陷就是若要提高单台机器的下载能力，就必须开更多的线程，而线程的开销也非常大，无论是内存或者cpu的调度都会给下载机器很大的压力。因此，多线程用于海量数据下载并不是一个最优的方案，而需要使用更高效的网络通信模型。

因此，提供一个能解决海量数据所引发的技术细节，更好完成下载服务，也才能为搜索引擎提供数据支持的高效和健壮的下载系统尤为重要。

发明内容

为克服上述现有技术的不足，本发明提供一种互联网爬虫的分布式下载系统。

实现上述目的所采用的解决方案为：

一种互联网爬虫的分布式下载系统，其改进之处在于：所述系统包括中心服务器、客户端、下载服务器和运用事件触发模型的DNS服务器集群。

进一步的，所述中心服务器实现所述下载服务器的下载调度，所述下载服务器完成下载任务；所述下载服务器周期性向所述中心服务器发送heartbeat和下载状态；

所述客户端向所述中心服务器发送下载请求，所述中心服务器根据所述下载服务器运行情况和下载服务类别的下载数量配额向所述客户端返回指令。

进一步的，所述返回指令包括以下情况：

若存在下载资源，则向所述客户端返回下载流水ID和下载服务器的IP；所述客户端向所述下载服务器发送所述下载流水ID和下载URL，所述下载服务器向所述中心服务器验证下载所述下载流水ID和下载URL是否有效，有效则进入预备下载队列，等待下载；所述下载服务器完成一条URL的下载后，将下载结果发送至所述客户端的接收端口，完成下载；

若不存在下载资源，则向所述下载服务器返回拒绝信号，所述下载服务器接收所述拒绝信号，等待一段时间再向所述中心服务器发送另一个下载请求。

进一步的，所述中心服务器启动时装载下载配额列表，所述下载配额列表包括多条数据，所述数据包含下载服务名和每一秒的下载配置数。

进一步的，所述中心服务器根据分布式系统的下载服务器运行情况和下载服务类别的下载数量配额向所述客户端返回指令包括以下步骤：

I、获取所述下载服务名每秒的配额数，若所述下载配额表之中不存在该服务名，返回no；

II、若存在此服务名，获取系统当前分钟的当前秒数s、每一秒的配额数m、该服务这一分钟内已分配的下载数据n，若t+n>s*m，t为客户端下载的URL的数目，返回no，否则进入步骤III；

c、遍历所有上报心跳数的下载服务器，如下式确定所述下载服务器剩余的槽数的预计值u，u＝p*s+q-r，其中，p为各个下载服务器上一次上报心跳的平均下载速度p，q为剩余槽数，r为这一分钟已经给此下载服务器分配的下载任务数；

若u>t，将所述下载服务器放入备选机器列表，待遍历整个下载服务器列表之后，若备选下载服务器列表为空，返回no，若存在多个备选下载服务器，选取u值最大的下载服务器，并赋值n＝n+t，r＝r+t，返回此机器IP和yes；

IV、每一分钟的1秒，中心服务器将遍历整个下载系统的各个下载服务，将已分配的URL数n清零,另外，遍历所有下载下载服务器列表，将每一个下载服务器的已分配的下载数目r清零，从而，当一个下一分钟开始时，整个下载系统恢复初始状态。

进一步的，所述DNS服务器集群使用事件触发模式进行下载，利用Libcares进行异步的DNS解析，提高下载速度。

进一步的，所述DNS服务器集群包括底层DNS server、上层DNS server和外网DNS server。

进一步的，所述下载服务器进行域名解析，向所述底层DNS server发送请求，若底层DNS查询不为空，则底层DNS server返回，否则向上层DNS server发送请求；

若上层DNS server查询不为空，则所述上层DNS server返回，否则向外网DNS server发送请求，外网DNS返回；

与对方服务器建立连接，发送下载请求，对方服务器响应，返回下载结果给所述下载服务器。

与现有技术相比，本发明具有以下有益效果：

1、本发明的系统解决了采用轻中心化的分布式模型，下载带宽控制，DNS解析系统3个策略来解决现有分布式下载系统的问题由于中心化的服务器负载过重，整个集群的下载带宽控制，以及域名解析和下载通信模型的几个问题，该系统能够提供高效、均衡的下载服务。

2、本发明的系统的中心服务器的负责调度下载带宽，压力很小，Slave与Master之间保持严格的C/S模型，客户端直接Slave通信，减少了网络传输。

3、本发明的系统保证了下载集群下载带度的使用率，并且不会影响其它的网络服务。

4、本发明的系统采用DNS解析系统和异步DNS解析，很好的解决了互联网大批量的DNS解析的问题；用于DNS解析的DNS集群服务器采用分层架构,既保证DNS解析速度，又不会对外网DNS服务器造成巨大的压力。

5、本发明的系统使用事件触发模式进行下载，减少了多线程模式的系统资源使用率，并且提高了下载速度。

6、本发明的系统采用主从模式下载服务集群，中心服务器Master是一个轻量级的服务，不负责具体的下载，但是负责整个下载集群的流量控制，使下载集群的带宽使用能保持一个平稳的使用率，既不出现高的峰谷，使下载占用机房的所有下行带宽，也不会出现波谷，使机房的下行带宽没有充分利用。通过一个很轻量级的服务，控制了整个下载系统的均衡性。

附图说明

图1为本实施例中互联网爬虫的分布式下载系统示意图。

具体实施方式

下面结合附图对本发明的具体实施方式做进一步的详细说明。

本发明提供了互联网爬虫的分布式系统的下载系统包括一个中心服务器(Master)、若干个下载服务器(Slave)、需要下载资源的客户端(Client)和运用事件触发模型的DNS服务器集群。

中心服务器(Master)，实现下载服务器的下载调度，不负责下载任务；

下载服务器(Slave)，完成具体的下载任务，下载服务器周期性向中心服务器发送心跳(Heartbeat，表示网络中的节点及确认其正常工作)和下载状态；通过心跳和心跳的附属信息，确认下载服务器仍正常，防止客户端将一要下载的url发送给一个已经当机的slave。

上述下载状态包括下载成功数、失败数、速率、目前此下载服务器可用的下载空闲的槽数等。

客户端(Client)，一个需要下载资源的程序，向所述中心服务器发送下载请求，中心服务器根据分布式系统的下载服务器运行情况和下载服务类别的下载数量配额向所述客户端返回指令。

中心服务器(Master)在接受下载服务器(Slave)的状态报告之后，更新自己的内存下载服务器(Slave)下载服务的状态。中心服务器(Master)与下载服务器(Slave)之间遵守严格的Server/Client模型，中心服务器(Master)不主动向下载服务器(Slave)发送请求，下载服务器(Slave)向中心服务器(Master)主动上报心跳，若某个下载服务器(Slave)在2个周期之内没有上报心跳，那么中心服务器(Master)在接受到客户端(Client)的下载要求之后，将此下载服务器(Slave)排除在外，客户端(Client)不会向一个已死的下载服务器(Slave)发送下载URL。

DNS服务器集群，使用事件触发模式进行下载，利用Libcares进行异步的DNS解析，提高下载速度。

事件触发模型(或称事件驱动模型，event-driven)，为一种网络通信方式，代表是linux之下的epoll与windows之下的完成端口。本发明中，实际使用的是包装epoll的libevent,本质为用一个线程去监听很多的网络套接字(socket)，并且由底层硬件驱动，从而提高读与写的速度，且由于以上操作为单线程操作，所用cpu与内存资源都较少。相比于传统的多线程下载模型来说，若要并发下载2000个网页需开启2000个线程，而2000个线程对于操作的cpu与内存是一个极大的开销。本发明的系统采用事件驱动模式，只需一个线程去监听2000个套接字即可。最大占用一个cpu，没有多作的线程开销，并且读写速度也更快。

事件驱动的通信应用在两个方面：DNS集群之间的通信和slave下载具体网页的与对方服务器的通信。

如图1所示，图1为本实施例中互联网爬虫的分布式下载系统示意图；本实施例的下载系统包括：一个中心服务器(Master)、两个下载服务器(Slave)Slave1和Slave2、客服端(Client)和DNS服务器集群。

下载服务器Slave1与Slave2是对等关系，均需完成发送心跳和接受下载任务。向中心服务器(Master)发出下载的请求，提供需要批量下载的URL数量和此类下载服务的名称，中心服务器(Master)根据目前整下载系统下载服务器(Slave)运行情况和具体的下载服务类别的下载数量配额完成下载调度，对于客户端的请求做出回应，包括两种情况，本实施例中认为Slave2为最合适的Slave，以此为例具体说明：

(A)、如果目前有下载资源，则向Client返回一个下载流水ID及Slave的IP，上述下载流水ID为一个递增的数字ID，用于防止重复下载，Slave的IP是一个最合适的下载Slave的IP；Client在接受这个下载流水ID和Slave的IP后，向此IP的Slave发送相应的下载流水ID及需要下载的这一批URL，Slave接受此下载流水ID以及这一批URL，向Master进行验证这个下载流水ID是否有效(也可以省略此步验证)，再将这一批URL放入自已的预备下载队列，等待下载，当Slave完成某一条URL的下载之后，将下载结果发送给客户端Client的接收端口，完成下载。

(B)、如果目前没有下载资源，如：目前没有可以提供下载的Slave或此类下载服务已经达到下载配额等情况，则向Client返回no，Client授受到no的消息之后，等待一段时间，再重新向Master发送另一个下载请求。

以上过程中，本实施例的Master在接受Slave的状态报告之后，更新自己的内存Slave下载服务的状态。Master与Slave之间遵守严格的Server/Client模型，Master不主动向Slave发送请求，Slave向Master主动上报心跳，若某个Slave在2个周期之内没有上报心跳，Master在接受到Client的下载要求之后，将此Slave排除在外，Client不会向一个已死的Slave发送下载URL。

本实施例中，若存在多个备选下载服务器，选取Slave剩余的槽数的预计值u值最大的下载服务器，认为该选择为最合适的下载服务器slave，选一个最空闲的slave。

本实施例中，中心服务器(Master)进行流量控制和下载资源分配，Master在启动时装载一个下载配额列表，此列表包括多条数据，一条数据包含一个下载服务名和每一秒的下载配置数。在接受到一个Client下载请求时，Client需要上报自已下载服务的名和下载的URL的数目t，Master在接受到这个请求之后，完成如下逻辑，实现根据分布式系统的下载服务器运行情况和下载服务类别的下载数量配额向客户端返回指令：

I、获取下载服务名每秒的配额数，若下载配额表之中没有此服务名，直接返回no。

II、如果此服务名存在，获取系统当前分钟的当前秒数s、每一秒的配额数m、此服务这一分钟之内已分配的下载数据n，如果t+n>s*m，代表配额已经分配完，返回no，否则进入步骤III；

III、如果t+n<s*m，表示这一分钟累计的下载配额仍然有剩余，遍历所有上报心跳数的Slave，根据各个Slave上一次上报心跳的平均下载速度设为p、Slave剩余的槽数q、这一分钟已经给此Slave分配的下载任务数r，如下式计算这个Slave剩余的槽数的预计值u：

u＝p*s+q-r；

比较u和t，若u>t，将此Slave放入备选机器列表，待遍历整个Slave列表之后，若备选机器列表为空，返回no，若有多个备选机器，从列表选取一个u最大的Slave机器，并进行赋值n＝n+t，r＝r+t，返回此机器IP和yes。

IV、每一分钟的第1秒，Master将遍历整个下载系统的各个下载服务，将已分配的URL数n清零，遍历所有下载slave机器列表，将每一个Slave的已分配的下载数目r清零，从而，当一个下一分钟开始时，整个下载系统恢复初始状态。

以上步骤解决整个下载系统中整个集群的下载带宽控制和各个下载系统下载配额的问题，且各个下载服务器Slave之间互不影响。

以上方法通过控制每一秒的URL分配数目，而每一秒没使用的下载配额，只在这一分钟之内有效，因此，基本上每一秒整个下载集群之上并发下载的URL数目是一定的，从而下载所占的带宽也是一定的，且带宽占用曲线不会出现很大的波峰和波谷，从整个防火墙的网络占用率图形上来看，基本上是一条平行的直线。

DNS解析广域网下载爬虫的关键。现有的解析方法为：操作系统自带的gethostbyname函数，此函数是一个同步的全局阻塞函数，为了加速下载，不能使用此函数进行域名解析，而要使用异步域名解析函数。另外，多线程在进行下载时并不能很好的提高并发，如果需要200并发，就要开启200线程，这样的下载模型对下载机器的cpu和内存都造成巨大的压力，因此，为了提高并发，需要使用事件触发模型，此模型只需要一个线程，操作系统完成套接字的可读和可写的触发，从而大大减轻Slave下载服务器的CPU和内存的压力。

本实施例中的DNS服务器集群运用事件触发模型进行下载，并利用Libcares进行异步DNS解析。通过事件触发模型和异步DNS解析，大大提高下载速度。

考虑DNS解析是一个非常耗时和复杂的请求，一次DNS请求需要递归查找，且各域名解析之后的结果记录有不同的生存周期，而生存周期是由于对方DNS服务器设置，有的非常短，几个小时，有的非常长，几个月也有可能。一般情况之下，生存周期非常短的DNS并不会在几个小时之内更改域名解析的IP，而非常长的生存周期的记录有时却会造成IP已经失效的问题。因此当搭建DNS解析系统之后，就可控制DNS记录的生成周期，将生存周期的短DNS记录加长，来减少重复的DNS查询次数，将生存周期长的DNS记录变短，减少DNS失效的情况。另外，对于大规模的下载程序来说，单台DNS解析服务器也会成瓶颈，从而必须使用DNS解析集群，Libcares支持多台DNS服务器进行轮流查找，但如果这些内部DNS服务器全部向外网的某台DNS服务器进行请求，就会造成对外网的DNS服务器压力过大，且内部的DNS服务器存储的数据基本上是相同的；因此DNS服务器需要使用层状结构，使用一台的DNS服务器向外界DNS发送请求，而其它的内部DNS服务器向这台DNS服务器发送请求，从而DNS解析是一个递归的过程，以上方案对于Libcares完全透明，能够很好的解决DNS数据共享的问题。

本实施例中，DNS服务器集群包括底层DNS服务器(底层DNS server)、上层DNS服务器(上层DNS server)和外网DNS服务器(外网DNS server)。

底层DNS服务器负责为Slave提供DNS查询服务，若底层DNS服务器不包含某个查询的结果，向上层DNS服务器发送请求，反之，直接返回给Slave内存的结果。上层DNS服务器在接受到底层DNS服务器之后，如果内存中有相应的记录，直接返回，反之，向外网DNS服务器发送请求。

只有一个上层DNS服务器向外网发送请求，从而减轻对外网DNS服务器的压力。且，上层DNS服务器为底层的DNS服务器提供一级缓存机制。

本实施例中，DNS服务器集群的操作过程如下：

下载服务器进行域名解析，向底层DNS服务器发送请求，若底层DNS查询不为空，则底层DNS server返回，否则向上层DNS server发送请求；

若上层DNS server查询不为空，则上层DNS server返回，否则向外网DNS server发送请求，外网DNS返回；

与对方服务器建立连接，发送下载请求，对方服务器响应，返回下载结果给所述下载服务器。

最后应当说明的是:以上实施例仅用于说明本申请的技术方案而非对其保护范围的限制,尽管参照上述实施例对本申请进行了详细的说明,所属领域的普通技术人员应当理解:本领域技术人员阅读本申请后依然可对申请的具体实施方式进行种种变更、修改或者等同替换，但这些变更、修改或者等同替换，均在申请待批的权利要求保护范围之内。

Claims (8)

1.一种互联网爬虫的分布式下载系统，其特征在于：所述系统包括中心服务器、客户端、下载服务器和运用事件触发模型的DNS服务器集群。

2.如权利要求1所述的系统，其特征在于：所述中心服务器实现所述下载服务器的下载调度，所述下载服务器完成下载任务；所述下载服务器周期性向所述中心服务器发送heartbeat和下载状态；

所述客户端向所述中心服务器发送下载请求，所述中心服务器根据所述下载服务器运行情况和下载服务类别的下载数量配额向所述客户端返回指令。

3.如权利要求2所述的系统，其特征在于：所述返回指令包括以下情况：

若存在下载资源，则向所述客户端返回下载流水ID和下载服务器的IP；所述客户端向所述下载服务器发送所述下载流水ID和下载URL，所述下载服务器向所述中心服务器验证下载所述下载流水ID和下载URL是否有效，有效则进入预备下载队列，等待下载；所述下载服务器完成一条URL的下载后，将下载结果发送至所述客户端的接收端口，完成下载；

若不存在下载资源，则向所述下载服务器返回拒绝信号，所述下载服务器接收所述拒绝信号，等待一段时间再向所述中心服务器发送另一个下载请求。

4.如权利要求1所述的系统，其特征在于：所述中心服务器启动时装载下载配额列表，所述下载配额列表包括多条数据，所述数据包含下载服务名和每一秒的下载配置数。

5.如权利要求2所述的系统，其特征在于：所述中心服务器根据分布式系统的下载服务器运行情况和下载服务类别的下载数量配额向所述客户端返回指令包括以下步骤：

I、获取所述下载服务名每秒的配额数，若所述下载配额表之中不存在该服务名，返回no；

II、若存在此服务名，获取系统当前分钟的当前秒数s、每一秒的配额数m、该服务这一分钟内已分配的下载数据n，若t+n>s*m，t为客户端下载的URL的数目，返回no，否则进入步骤III；

III、遍历所有上报心跳数的下载服务器，如下式确定所述下载服务器剩余的槽数的预计值u，u＝p*s+q-r，其中，p为各个下载服务器上一次上报心跳的平均下载速度p，q为剩余槽数，r为这一分钟已经给此下载服务器分配的下载任务数；

若u>t，将所述下载服务器放入备选机器列表，待遍历整个下载服务器列表之后，若备选下载服务器列表为空，返回no，若存在多个备选下载服务器，选取u值最大的下载服务器，并赋值n＝n+t，r＝r+t，返回此机器IP和yes；

IV、每一分钟的1秒，中心服务器将遍历整个下载系统的各个下载服务，将已分配的URL数n清零,另外，遍历所有下载服务器列表，将每一个下载服务器的已分配的下载数目r清零，从而，当一个下一分钟开始时，整个下载系统恢复初始状态。

6.如权利要求1所述的系统，其特征在于：所述DNS服务器集群使用事件触发模式进行下载，利用Libcares进行异步的DNS解析，提高下载速度。

7.如权利要求1所述的系统，其特征在于：所述DNS服务器集群包括底层DNS server、上层DNS server和外网DNS server。

8.如权利要求7所述的系统，其特征在于：所述下载服务器进行域名解析，向所述底层DNS server发送请求，若底层DNS查询不为空，则底层DNS server返回，否则向上层DNSserver发送请求；

若上层DNS server查询不为空，则所述上层DNS server返回，否则向外网DNS server发送请求，外网DNS返回；

与对方服务器建立连接，发送下载请求，对方服务器响应，返回下载结果给所述下载服务器。