spider啊spider！2007-03-06 14:132005, August 21, 2:27 AM.

突然有个想法，做一个小程序来分析各个搜索引擎Spider的抓取规律，现有的日志分析程序仅能提供一点点网站访量的基本信息，根本无法提供针对搜索引擎spider的详细分析。

　　这个小程序最好能提供网站每日被各个spider抓取网页的数量、抓取时间段分布、抓取间隔、抓取时网页状态代码分布等细节信息。然后还有针对每个页面的各个spider的访问情况统计：抓取次数、检查更新频率、状态代码等等。呵呵，如果可能的话，针对网站上的新网页抓取速度研究也是很不错的方向。

　　研究spider抓取网页的数量、抓取间隔、更新频率你可以明白你的网站被搜索引擎重视的程度，spider是搜索引擎的脸，最能体现搜索引擎对你网站的看法，更新速度越快，那证明你的网站就越受搜索引擎欢迎：一方面新网页总是受到搜索引擎的特殊照顾，排的会比较靠前，更新越快，就越有优势；另一方面谁会花大把的力气在一堆垃圾上呢，它天天抓你网页，当然是把你当宝贝了：）。（谬论哈，谬论）

　　针对单页面的spider抓取研究也很重要，如果spider总是以比整站平均更新频率高许多的频率抓取某些页面，那就证明搜索引擎十分的重视这些页面，这些页面应该包括两类：索引页和重要内容页面。索引页是spider发现新内容的主要来源，是spider的庄稼地，它要不停的从这里收口粮（比如首页，googlebot差不多每天都要抓一、两次甚至更多）；重要的内容页搜索引擎也会很重视，怕错过了重要内容的更新或者这个页面的消失：）。

　　状态代码也很重要，如果spider总是来爬呀爬，但有更新过网页却总是304，那就要好好研究一下为什么了。404一定要尽量避免，一个满是死链的站点恐怕谁都不喜欢看。200才是我最喜欢看的。

　　如果真能研究出规律，就可以针对搜索引擎做网站的整体优化、设计，spider喜欢的就多做，spider不喜欢的扔掉也无所谓吧，搜索引擎搜不到，做它有啥用？

　　每天在看我网站的日志，越来越感到靠偶的脑袋分析是个不可能完成的任务，最早的时候日志只有几M大，很容易就可以分析完，现在的日志有将近200M了，用ultraedit打开需要一分多钟的时间，从日志中抽取spider部分都是很大的麻烦，分析感觉成了不可能完成的任务。尝试用access分析，但是access只能支持几万条数据，好象让猫拉驴车的感觉，机器死掉了也做不完一个查询，其它的数据库没有接触过，看来得从头学习了。

　　分享一点经验：
　　msnbot属于细水长流型，每天抓取1500－2000页，不会多也不会少。
　　baiduspider属于老虎型，一口就会把你的网站整个吃下去，以后也会天天来舔一舔剩下的骨头渣。
　　googlebot属于高深莫测型，高兴了就十几个IP一起爬，不高兴了爬个首页就走了。除了首页更新频繁、新出网页收录较快以外，暂时分析不出太多的规律，sitemaps也会天天抓几次，但是好象没有效果。
　　Yahoo! Slurp属于尝鲜型，至少我的网站如此：它只抓取并在搜索结果中更新网站中最新的网页，并且排的十分靠前，旧网页也会抓许多，但是却需要很长时间才能在搜索结果中出现，并且排的都比较靠后。

msn、yahoo、google有个共同的特点就是他会用不同的IP抓取你的网站，baidu等国内的搜索引擎会习惯于始终使用同一个spider抓取你的网站。

真的很相似吗？——与《Spider系统中LRU算法的使用和实现》的作者商榷
《程序员》杂志2007年第1期刊载了洪伟铭先生的文章《Spider系统中LRU算法的使用和实现》（以下简称《使用与实现》），恰好，本人也有过开发Spider软件的经验，对文中的某些看法不敢苟同，特商榷如下。

不错，如《使用与实现》所言，Spider需要解决的一大问题就是URL排重。可以说，抓取的效率在很大程度上取决于排重的效率，因为互联网的各页面之间是靠超链接建立联系的，页面抓取程序必须依靠链接来抓取各个页面，如果多个链接指向同一个地址，而又没有排除重复，就可能多次抓取一个页面，不但效率低下，而且可能造成数据冗余（此处暂不考虑不同URL对应重复内容的问题）。
《使用与实现》文中举了抓取新浪新闻的例子，如果每秒抓取10个页面，就必须进行900－1000次排重操作（实际上，笔者认为，这样的抓取必须首先筛选出符合某种Pattern的URL，而不能眉毛胡子一把抓），但“新”（也就是未抓取过）的URL只有几个，（所以）这种情况非常类似于操作系统中的虚拟存储器管理，所以可以使用LRU算法来解决此问题。

我所不同意的，正是“所以”的推论。

众所周知，LRU是虚拟存储系统采用的算法之一（这里姑且不论《使用与实现》文中混淆了算法的实现手段(“每次命中则加1”只是实现手段之一)和算法本身），虚拟存储系统所要解决的问题是，在以少量资源（物理空间）虚拟大量资源（逻辑空间）时，可用资源的使用（替换）策略，也就是说，“虚拟”哪些逻辑资源的问题。LRU算法的思想是，“虚拟”最近使用过的资源，“不虚拟”长时间未使用过的资源。LRU算法的理论依据是程序的局部性原理：最近使用过的资源，最有可能在将来使用，因此需要替换长时间未使用过的资源。
这样一来，LRU算法的思想，及其适于解决的问题的性质，就大致清楚了。下面我们来看，URL排重是否“非常类似于”虚拟存储系统管理。

首先，URL排重是否需要用少量可用资源来虚拟大量逻辑资源，如果答案是肯定的，也就是说，将所有已经抓取过的URL作为“大量资源”，而Cache作为“少量资源”，那么策略就是，遇到一个URL，首先在Cache中检索，如果不存在（未命中），则去后备存储器（如数据库）中寻找，不幸的是，我们在原文中未能发现这类逻辑。而且，如果抓取的规模不大，完全可以在内存中以Hash方式进行排重，这样的时间代价是O(1)，如果抓取规模很大，维护链表进行URL排重显然不能胜任。
其次，URL排重是否具备“局部性”特征，也就是说，最近出现过的URL是否最有可能在未来出现？以我的经验，似乎并不存在这样的规律。一方面因为网络上各个页面之间的关系错综复杂，例如“相关新闻”关联的很可能并不是最近出现的新闻；另一方面，需要排重的URL序列与Spider抓取机制有很大的关系，如果多个Spider的工作比较分散，则“局部性”几乎不可见。

实际上，我认为，进行URL排重，最合适的思维应该是集合（Set），这才是解决重复问题的要点。
《使用与实现》使用一个HashMap加上双向链表（其实LRU的实现思路是带启发式规则的自组织线性表）的实现，不但编写起来很麻烦（“将命中的节点提前到链表开头”的操作，因为只能使用线性检索，如果链表达到一定长度，效率很低），也不容易理解（没有按照思维模型进行包装）。
如果我来设计，此系统首先必须是实现Set接口，以便外部操作，内部以规模有限的，能够按照某种规则进行调整的数据结构（例如SortedSet，用以实现LRU）来实现。这样，对外部调用程序隐藏了实现，程序的逻辑也较为清晰。

Trackback: http://tb.donews.net/TrackBack.aspx?PostId=1115150