不简单的URL去重

转自：http://blog.csdn.net/historyasamirror/article/details/6746217

发现我有好几篇blog的前缀都是用的“不简单”，它大概描述了这样一个状态：一个看起来很简单的任务在实践之后，发现其实很不容易。很多事情都是这样，如果不是亲自去做，如果不是仔细钻研，那就只能处于雾里看花的状态。

这让我想到另一个故事，在我毕业的那年曾经被某公司的CTO面试，他和我说过一句话让我至今记忆犹新，他跟我说技术其实是很简单的（几年后某位大牛也和我表达过类似的意思）。我一直琢磨这句话的含义，现在理解，他的意思应该是指无论多难的技术，只要你用心，总是能够学习和掌握的。

简单或者不简单，其实不是技术，而是我们做事的态度。

言归正传。
所谓的Url去重（我一直没找到对应的英文，URL Filtering ?），就是爬虫将重复抓取的URL去除，避免多次抓取同一网页。爬虫一般会将待抓取的URL放在一个队列中，从抓取后的网页中提取到新的URL，在他们被放入队列之前，首先要确定这些新的URL没有被抓取过，如果之前已经抓取过了，就不再放入队列。

最直观的做法 – hash表

为了尽快把整个爬虫搭建起来，最开始的URL去重采用方案是一个内存中的HashSet，这是最直观的方法，所有人都能想得到。HashSet中放置的就是URL的字符串，任何一个新的URL首先在HashSet中进行查找，如果HashSet中没有，就将新的URL插入HashSet，并将URL放入待抓取队列。
这个方案的好处是它的去重效果精确，不会漏过一个重复的URL。它的缺点是，我的爬虫第二天早上就挂了，Out Of Memory。因为随着抓取网页的增加，HashSet会一直无限制的增长。另外，网络中的很多URL其实是很长的，有大量的URL长度达到上百个字符。当然，因为我的爬虫是跑在一个小服务器上，JVM的内存本来就不多，否则它应该能再多撑1-2天。
简单估算一下，假设单个URL的平均长度是100 byte（我觉着这已经非常保守了），那么抓取1000万的URL就需要：
100 byte * 10 000 000 = 1 GB
而1000万URL在整个互联网中实在是沧海一粟。可以了解，需要多大的内存才能装下所有URL的HashSet。

压缩URL

为了我的爬虫能再多撑几天，同时不想改动太多的代码，第二个版本增加了一个小功能，就是HashSet中不存储原始的URL，而是将URL压缩后再放进去。貌似有不少paper中讨论过如何对URL进行压缩，包括新浪微博中的短URL其实也是个不错的方案，可惜这些方法我都不会。为了偷懒，我直接用MD5对URL做编码。
MD5的结果是128 bit也就是16 byte的长度。相比于之间估计的URL平均长度100byte已经缩小了好几倍，可以多撑好多天了。
当然，哪怕找个一个可以压缩到极致的算法，随着URL越来越多，终有一天会Out Of Memory。所以，这个方案不解决本质问题。
MD5另外一个问题是，有可能两个相同的URL被映射成同一个MD5值，这样的话，它们中有一个就永远不会被抓取了。我不太确定的是，这个概率会有多大。如果非常小的话，这微小的误差倒也不会有太大影响。

Bloom Filter

基于内存的HashSet的方法存在一个本质的问题，就是它消耗的内存是随着URL的增长而不断增长的。除非能够保证内存的大小能够容纳下所有需要抓取的URL，否则这个方案终有一天会到达瓶颈。
这时候就会想，要找一个类似于HashSet的但所消耗的内存相对固定而不会不断增长的方案，于是自然想到了Bloom Filter。关于Bloom Filter的概念这里就不多谈了，网上随处可以找到。我简单尝试了一下Bloom Filter，但是很快就放弃了。基于Bloom Filter的方案有几个问题：
第一个是理论上的。Bloom Filter会将一些正常的样本（在我这就是没有抓取过的URL）过滤掉，即所谓的False Positive。当然，这概率有多大，取决于Bloom Filter的参数设置。但这引出了下一个问题；
第二个是实践中的，即Bloom Filter的那几个参数应该如何设置？m，k，n应该设置成多少才合适，这个我没有经验，而且可能需要反复的实验和测试才能够比较好的确定下来；
以上两个问题还不是我放弃Bloom Filter的根本原因，真实的原因是我在做的是一个爬虫框架，上面可以会启动很多的爬虫任务，每个任务可能抓取自己特定的URL，而且任务之间是独立的。这样，对于每个任务都需要有一个Bloom Filter，虽然对于单一任务它使用Bloom Filter所消耗的内存是固定的，但是任务的增多会导致更多的Bloom Filter，从而导致更多的内存消耗。仍然存在内存溢出的可能。
但如果只是一个抓取任务，那么采用Bloom Filter应该是一个非常不错的选择。

BerkeleyDB

我终于明白我所需要的其实是一个可以放在disk上的去重方案，这样，内存溢出将永远成不了可能。很早就知道有BerkeleyDB这么一个东西，但第一次真正了解还是在Amazon的Dynamo那篇论文中提到过采用了BerkeleyDB作为单机上的底层存储。当时觉着这东西真另类，原来还有叫做“DB”的东西却不支持SQL。那时候还没有NOSQL这词，把这样的东西叫做non-relational database。
BerkeleyDB是一个key-value database，简单的说，就是一个在disk上的hash表，这也是为什么它可以被用来做URL去重的原因。它另外一个另类的地方是，它是和程序运行在同一个进程空间中的，而不像一般的db，是做为单独的程序运行。
这里附上Heritrix中使用BerkeleyDB做URL去重的代码，一探究竟：（代码位于Heritrix源代码的org.archive.crawler.util.BdbUriUniqFilter）

有一堆做初始化和配置的函数就直接忽略了，真正相关的函数就只有两个：

/**
*Createfingerprint.
*PubicaccesssotestcodecanaccesscreateKey.
*@paramuriURItofingerprint.
*@returnFingerprintofpassed<code>url</code>.
*/
publicstaticlongcreateKey(CharSequenceuri){
Stringurl=uri.toString();
intindex=url.indexOf(COLON_SLASH_SLASH);
if(index>0){
index=url.indexOf('/',index+COLON_SLASH_SLASH.length());
}
CharSequencehostPlusScheme=(index==-1)?url:url.subSequence(0,index);
longtmp=FPGenerator.std24.fp(hostPlusScheme);
returntmp|(FPGenerator.std40.fp(url)>>>24);
}

/**
*value:only1byte
*/
privatestaticDatabaseEntryZERO_LENGTH_ENTRY=newDatabaseEntry(
newbyte[0]);

protectedbooleansetAdd(CharSequenceuri){
DatabaseEntrykey=newDatabaseEntry();
LongBinding.longToEntry(createKey(uri),key);
longstarted=0;

OperationStatusstatus=null;
try{
if(logger.isLoggable(Level.INFO)){
started=System.currentTimeMillis();
}
status=alreadySeen.putNoOverwrite(null,key,ZERO_LENGTH_ENTRY);
if(logger.isLoggable(Level.INFO)){
aggregatedLookupTime+=
(System.currentTimeMillis()-started);
}
}catch(DatabaseExceptione){
logger.severe(e.getMessage());
}
if(status==OperationStatus.SUCCESS){
count++;
if(logger.isLoggable(Level.INFO)){
finalintlogAt=10000;
if(count>0&&((count%logAt)==0)){
logger.info("Averagelookup"+
(aggregatedLookupTime/logAt)+"ms.");
aggregatedLookupTime=0;
}
}
}
if(status==OperationStatus.KEYEXIST){
returnfalse;//notadded
}else{
returntrue;
}
}

简单解释一下：

第一个函数createKey是在做URL的压缩，它将任意长度的URL转换成一个long型的值。long型的取值范围有2^64，因此两个URL映射成同一个long型值的概率应该挺低的。但我也没太细看这个函数，所以它的效果到底如何不确定。

第二个函数setAdd就是将被压缩的URL写入到BerkeleyDB。之前说过，BerkeleyDB是一个key-value database，它的每条记录都包括了一个key和一个value。但是在URL去重中，value不重要（比如我们之前内存中用的也是HashSet而不是HashMap），因此这里统一用一个byte长度的值来表示value，就是这个static变量ZERO_LENGTH_ENTRY。

别看setAdd有这么多行，真正有用的就这一行：

status=alreadySeen.putNoOverwrite(null,key,ZERO_LENGTH_ENTRY);

将压缩后得到的long型值作为key，ZERO_LENGTH_ENTRY作为value插入到BerkeleyDB中，如果db中已经有了这个long型值，就会返回OperationStatus.KEYEXIST，表示对应的URL之前已经抓取到了，那么这个URL就不会放入待抓取队列中。

最后

比较遗憾的是，我还没抽出空对BerkeleyDB这个方案做性能测试，不确定它每秒能执行多少次setAdd操作，是否足够满足我们性能的要求。以后补上。

另外，虽然我不了解，但我认为像百度这样专业的搜索引擎，它的爬虫的URL去重方案可能比这里列举的要复杂的多，毕竟那个的各方面的要求也要更高。