爬虫设计

从Larbin看互联网爬虫设计

于敦德
2005.12.16
转载请注明出处

互联网是一个庞大的非结构化的数据库，将数据有效的检索并组织呈现出来有着巨大的应用前景，尤其是类似RSS的以XML为基础的结构化的数据越来越多，内容的组织方式越来越灵活，检索组织并呈现会有着越来越广泛的应用范围，同时在时效性和可读性上也会有越来越高的要求。这一切的基础是爬虫，信息的来源入口。一个高效，灵活可扩展的爬虫对以上应用都有着无可替代的重要意义。

要设计一个爬虫，首先需要考虑的效率。对于网络而言，基于TCP/IP的通信编程有几种方法。

第一种是单线程阻塞，这是最简单也最容易实现的一种，一个例子：在Shell中通过curl，pcregrep等一系统命令可以直接实现一个简单的爬虫，但同时它的效率问题也显而易见：由于是阻塞方式读取，dns解析，建立连接，写入请求，读取结果这些步骤上都会产生时间的延迟，从而无法有效的利用服务器的全部资源。

第二种是多线程阻塞。建立多个阻塞的线程，分别请求不同的url。相对于第一种方法，它可以更有效的利用机器的资源，特别是网络资源，因为无数线程在同时工作，所以网络会比较充分的利用，但同时对机器CPU资源的消耗也是比较大，在用户级多线程间的频繁切换对于性能的影响已经值得我们考虑。

第三种是单线程非阻塞。这是目前使用的比较多的一种做法，无论在client还是server都有着广泛的应用。在一个线程内打开多个非阻塞的连接，通过poll/epoll/select对连接状态进行判断，在第一时间响应请求，不但充分利用了网络资源，同时也将本机CPU资源的消耗降至最低。这种方法需要对dns请求，连接，读写操作都采用异步非阻塞操作，其中第一种比较复杂，可以采用adns作为解决方案，后面三个操作相对简单可以直接在程序内实现。

效率问题解决后就需要考虑具体的设计问题了。

url肯定需要一个单独的类进行处理，包括显示，分析url，得到主机，端口，文件数据。

然后需要对url进行排重，需要一个比较大的url Hash表。

如果还要对网页内容进行排重，则还需要一个Document Hash表。

爬过的url需要记录下来，由于量比较大，我们将它写到磁盘上，所以还需要一个FIFO的类(记作urlsDisk)。

现在需要爬的url同样需要一个FIFO类来处理，重新开始时，url会从定时从爬过的url FIFO里取出来，写到这个FIFO里。正在运行的爬虫需要从这个FIFO里读数据出来，加入到主机类的url列表里。当然，也会从前一个FIFO里直接读url出来，不过优先级应该比这个里面出来的url低，毕竟是已经爬过的。

爬虫一般是对多个网站进行爬取，但在同时站点内dns的请求可以只做一次，这就需要将主机名独立于url，单独有一个类进行处理。

主机名解析完成后需要有一个解析完成的IP类与之应用，用于connect的时候使用。

HTML文档的解析类也要有一个，用来分析网页，取出里面的url，加入到urlsDisk。

再加上一些字符串，调度类，一个简单的爬虫基本上就完成了。

以上基本上是Larbin的设计思路，Larbin在具体实现上还有一些特殊的处理，例如带了一个webserver，以及对特殊文件的处理。 Larbin有一点设计不不太好，就是慢的访问会越来越多，占用大量的连接，需要改进，另外如果对于大规模的爬虫，这仅仅实现了抓取的部分，要分布式的扩展还需要增加url的集中管理与调度以及前台spider的分布式算法。

 

 

用python编写分布式爬虫
1、 网络连接需要持续连接（persistent connection），DNS解析的瓶颈（先查本地DNS缓存）

实现方法:基于python httplib（对http1.1完成对持续连接的支持(python的httplib完全支持http1.1)，如果不是http1.1那么可以使用urlopen对其进行一次连接）并对其socket对象进行控制,关键是加入对读取DNS本地缓存(在我的机制下这个根本就不是主要问题可以暂时忽略)，以及有settimeout(Igloo)(搞定,就用setdefaulttimeout())的支持(或者利用自己的DNS服务器,进行优化处理),以及对sock对象的settimeout进行设置,防止长时间的等待一个有可能连接不上的web服务器.(要测试一下连接模块和DNS解析模块在访问不存在url在默认情况下的时间消耗)对站点的ip解析出来后就直接用ip进行连接而避免了重复调用DNS解析.例子:socket.gethostbyname("www.163.com")

网络连接下载模块非常重要，需要精心反复测试，因为有可能碰到一些不规范的web服务器，如果没有加以考虑会使整个线程崩溃。

   
2、    多线程:机器任务的分配及站点任务的分配。

实现方法：（在某台机器上实现，在对本机内存cpu的消耗情况判断后对机器任务进行分配；在对和站点的连接情况进行判断后对站点任务进行分配）
机器任务的分配：对于机器负担的情况调整在一个机器开的线程的个数。（在关闭线程时注意要先让线程完成当前运行任务）
站点任务的分配：就是某个机器对一个站点开的线程的个数的分配。（同样是要注意关闭线程时先让其完成当前任务）

3、    对web文件树遍历过程更好的控制，对web文件树在广度优先遍历时层次的判断。（整个网络是一个图，而某个站点的模型更接近于一棵树）

实现方法：在每个地址进入队列时加一个层次号，那么要遍历第n层的话那么遍历到第一个n+1就停止读取。

4、    利用robotparser解析robots.txt

5、    单个机器spider的作用：

a)    同2多线程3文件树的遍历

b)    将获取的外部url发回中央控制器，并从中央控制器取回新的外部url。

6、    中央控制器的作用：

a)    观察各机器的状态包括：cpu、内存、线程、站点、网络流量
b)    观察对外整体网络流量和连接状况，可以根据网络状况来调节timeout。

c)    接受各个机器发送过来的外部url并对每个url的重复数字计数。然后分配到各个机器。（分配时要用爬行策略控制器对外部url进行排序来分配，Igloo利用Page Rank，我们可以使用最简单的重复越多重要系数就越高来进行排序）

d)    分布式URL分配算法：Igloo1.2的二级哈希映射算法（集中式分配算法那个中央控制器容易成为系统瓶颈）复习哈希算法，还有就是对url是否访问过的判断（Igloo使用的是URL Trie滞后合并策略）。可以使用Berkeley DB作为URL Trie的替代品。两种实现方式的比较：

i.    现在的想法：（面向站点，信息颗粒大）外部链接只是保存主机名比如:www.163.com, 站内访问用解析好的ip地址维持连接，用相对链接来得到各个页面，这样就要维护一个外部链接列表，几个站点的链接列表。优点：节省内存，对某个站点的信息获取全面，对站点的出现频率统计，排序，重要站点先取。 缺点：对链接的获取的全面性得不到保证，而且不能获取更多的重要页面，每个站点的重要页面也不会很多。
ii.    老方案：（面向页面，信息颗粒小）所有连接一视同仁。缺点：浪费资源，对单一站点的获取不一定全面。优点：可以得到全面的链接图，可以使用Page Rank对列表进行排序，页面更重要就在最前面。

7、    解析html（超级链接的提取）搞定（用python的sgmllib）缺点：速度太慢（可能会造成瓶颈，要好好包装好，以后有机会换掉它）