java dataurl_java url参数去重
展開全部
言歸正e68a84e8a2ad62616964757a686964616f31333335326163傳。
所謂的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 plaincopy
/**
* Create fingerprint.
* Pubic access so test code can access createKey.
* @param uri URI to fingerprint.
* @return Fingerprint of passed url.
*/
public static long createKey(CharSequence uri) {
String url = uri.toString();
int index = url.indexOf(COLON_SLASH_SLASH);
if (index > 0) {
index = url.indexOf('/', index + COLON_SLASH_SLASH.length());
}
CharSequence hostPlusScheme = (index == -1)? url: url.subSequence(0, index);
long tmp = FPGenerator.std24.fp(hostPlusScheme);
return tmp | (FPGenerator.std40.fp(url) >>> 24);
}
[java] view plaincopy
/**
* value: only 1 byte
*/
private static DatabaseEntry ZERO_LENGTH_ENTRY = new DatabaseEntry(
new byte[0]);
protected boolean setAdd(CharSequence uri) {
DatabaseEntry key = new DatabaseEntry();
LongBinding.longToEntry(createKey(uri), key);
long started = 0;
OperationStatus status = 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 (DatabaseException e) {
logger.severe(e.getMessage());
}
if (status == OperationStatus.SUCCESS) {
count++;
if (logger.isLoggable(Level.INFO)) {
final int logAt = 10000;
if (count > 0 && ((count % logAt) == 0)) {
logger.info("Average lookup " +
(aggregatedLookupTime / logAt) + "ms.");
aggregatedLookupTime = 0;
}
}
}
if(status == OperationStatus.KEYEXIST) {
return false; // not added
} else {
return true;
}
}
簡單解釋一下：
第一個函數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 plaincopy
status = alreadySeen.putNoOverwrite(null, key, ZERO_LENGTH_ENTRY);
將壓縮后得到的long型值作為key，ZERO_LENGTH_ENTRY作為value插入到BerkeleyDB中，如果db中已經有了這個long型值，就會返回OperationStatus.KEYEXIST，表示對應的URL之前已經抓取到了，那么這個URL就不會放入待抓取隊列中。
最后
比較遺憾的是，我還沒抽出空對BerkeleyDB這個方案做性能測試，不確定它每秒能執行多少次setAdd操作，是否足夠滿足我們性能的要求。以后補上。
另外，雖然我不了解，但我認為像百度這樣專業的搜索引擎，它的爬蟲的URL去重方案可能比這里列舉的要復雜的多，畢竟那個的各方面的要求也要更高。
本回答由提問者推薦
已贊過
已踩過<
你對這個回答的評價是？
評論
收起
總結
以上是生活随笔為你收集整理的java dataurl_java url参数去重的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： java 链表算法_JAVA数据结构与算
- 下一篇： java抢答器代码_java竞争抢答器