不简单的URL去重

发现我有好几篇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）

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

[java]  view plain copy

1. /** 
2.  * Create fingerprint. 
3.  * Pubic access so test code can access createKey. 
4.  * @param uri URI to fingerprint. 
5.  * @return Fingerprint of passed <code>url</code>. 
6.  */  
7. public static long createKey(CharSequence uri) {  
8.     String url = uri.toString();  
9.     int index = url.indexOf(COLON_SLASH_SLASH);  
10.     if (index > 0) {  
11.         index = url.indexOf('/', index + COLON_SLASH_SLASH.length());  
12.     }  
13.     CharSequence hostPlusScheme = (index == -1)? url: url.subSequence(0, index);  
14.     long tmp = FPGenerator.std24.fp(hostPlusScheme);  
15.     return tmp | (FPGenerator.std40.fp(url) >>> 24);  
16. }  

[java]  view plain copy

1.     /** 
2.      * value: only 1 byte 
3.      */  
4.     private static DatabaseEntry ZERO_LENGTH_ENTRY = new DatabaseEntry(  
5.             new byte[0]);  
6.   
7.     protected boolean setAdd(CharSequence uri) {  
8.         DatabaseEntry key = new DatabaseEntry();  
9.         LongBinding.longToEntry(createKey(uri), key);  
10.         long started = 0;  
11.           
12.         OperationStatus status = null;  
13.         try {  
14.             if (logger.isLoggable(Level.INFO)) {  
15.                 started = System.currentTimeMillis();  
16.             }  
17.             status = alreadySeen.putNoOverwrite(null, key, ZERO_LENGTH_ENTRY);  
18.             if (logger.isLoggable(Level.INFO)) {  
19.                 aggregatedLookupTime +=  
20.                     (System.currentTimeMillis() - started);  
21.             }  
22.         } catch (DatabaseException e) {  
23.             logger.severe(e.getMessage());  
24.         }  
25.         if (status == OperationStatus.SUCCESS) {  
26.             count++;  
27.             if (logger.isLoggable(Level.INFO)) {  
28.                 final int logAt = 10000;  
29.                 if (count > 0 && ((count % logAt) == 0)) {  
30.                     logger.info("Average lookup " +  
31.                         (aggregatedLookupTime / logAt) + "ms.");  
32.                     aggregatedLookupTime = 0;  
33.                 }  
34.             }  
35.         }  
36.         if(status == OperationStatus.KEYEXIST) {  
37.             return false; // not added  
38.         } else {  
39.             return true;  
40.         }  
41.     }  

简单解释一下：

第一个函数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有这么多行，真正有用的就这一行：

[java]  view plain copy

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

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

最后

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

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