java dataurl_java url参数去重
展開全部
言歸正e68a84e8a2ad62616964757a686964616f31333335326163傳。
所謂的Url去重(我一直沒找到對應(yīng)的英文，URL Filtering ?)，就是爬蟲將重復(fù)抓取的URL去除，避免多次抓取同一網(wǎng)頁。爬蟲一般會將待抓取的URL放在一個隊列中，從抓取后的網(wǎng)頁中提取到新的URL，在他們被放入隊列之前，首先要確定這些新的URL沒有被抓取過，如果之前已經(jīng)抓取過了，就不再放入隊列。
最直觀的做法 – hash表
為了盡快把整個爬蟲搭建起來，最開始的URL去重采用方案是一個內(nèi)存中的HashSet，這是最直觀的方法，所有人都能想得到。HashSet中放置的就是URL的字符串，任何一個新的URL首先在HashSet中進(jìn)行查找，如果HashSet中沒有，就將新的URL插入HashSet，并將URL放入待抓取隊列。
這個方案的好處是它的去重效果精確，不會漏過一個重復(fù)的URL。它的缺點(diǎn)是，我的爬蟲第二天早上就掛了，Out Of Memory。因為隨著抓取網(wǎng)頁的增加，HashSet會一直無限制的增長。另外，網(wǎng)絡(luò)中的很多URL其實是很長的，有大量的URL長度達(dá)到上百個字符。當(dāng)然，因為我的爬蟲是跑在一個小服務(wù)器上，JVM的內(nèi)存本來就不多，否則它應(yīng)該能再多撐1-2天。
簡單估算一下，假設(shè)單個URL的平均長度是100 byte(我覺著這已經(jīng)非常保守了)，那么抓取1000萬的URL就需要：
100 byte * 10 000 000 = 1 GB
而1000萬URL在整個互聯(lián)網(wǎng)中實在是滄海一粟?？梢粤私?#xff0c;需要多大的內(nèi)存才能裝下所有URL的HashSet。
壓縮URL
為了我的爬蟲能再多撐幾天，同時不想改動太多的代碼，第二個版本增加了一個小功能，就是HashSet中不存儲原始的URL，而是將URL壓縮后再放進(jìn)去。貌似有不少paper中討論過如何對URL進(jìn)行壓縮，包括新浪微博中的短URL其實也是個不錯的方案，可惜這些方法我都不會。為了偷懶，我直接用MD5對URL做編碼。
MD5的結(jié)果是128 bit也就是16 byte的長度。相比于之間估計的URL平均長度100byte已經(jīng)縮小了好幾倍，可以多撐好多天了。
當(dāng)然，哪怕找個一個可以壓縮到極致的算法，隨著URL越來越多，終有一天會Out Of Memory。所以，這個方案不解決本質(zhì)問題。
MD5另外一個問題是，有可能兩個相同的URL被映射成同一個MD5值，這樣的話，它們中有一個就永遠(yuǎn)不會被抓取了。我不太確定的是，這個概率會有多大。如果非常小的話，這微小的誤差倒也不會有太大影響。
Bloom Filter
基于內(nèi)存的HashSet的方法存在一個本質(zhì)的問題，就是它消耗的內(nèi)存是隨著URL的增長而不斷增長的。除非能夠保證內(nèi)存的大小能夠容納下所有需要抓取的URL，否則這個方案終有一天會到達(dá)瓶頸。
這時候就會想，要找一個類似于HashSet的但所消耗的內(nèi)存相對固定而不會不斷增長的方案，于是自然想到了Bloom Filter。關(guān)于Bloom Filter的概念這里就不多談了，網(wǎng)上隨處可以找到。我簡單嘗試了一下Bloom Filter，但是很快就放棄了。基于Bloom Filter的方案有幾個問題：
第一個是理論上的。Bloom Filter會將一些正常的樣本(在我這就是沒有抓取過的URL)過濾掉，即所謂的False Positive。當(dāng)然，這概率有多大，取決于Bloom Filter的參數(shù)設(shè)置。但這引出了下一個問題；
第二個是實踐中的，即Bloom Filter的那幾個參數(shù)應(yīng)該如何設(shè)置？m，k，n應(yīng)該設(shè)置成多少才合適，這個我沒有經(jīng)驗，而且可能需要反復(fù)的實驗和測試才能夠比較好的確定下來；
以上兩個問題還不是我放棄Bloom Filter的根本原因，真實的原因是我在做的是一個爬蟲框架，上面可以會啟動很多的爬蟲任務(wù)，每個任務(wù)可能抓取自己特定的URL，而且任務(wù)之間是獨(dú)立的。這樣，對于每個任務(wù)都需要有一個Bloom Filter，雖然對于單一任務(wù)它使用Bloom Filter所消耗的內(nèi)存是固定的，但是任務(wù)的增多會導(dǎo)致更多的Bloom Filter，從而導(dǎo)致更多的內(nèi)存消耗。仍然存在內(nèi)存溢出的可能。
但如果只是一個抓取任務(wù)，那么采用Bloom Filter應(yīng)該是一個非常不錯的選擇。
BerkeleyDB
我終于明白我所需要的其實是一個可以放在disk上的去重方案，這樣，內(nèi)存溢出將永遠(yuǎn)成不了可能。很早就知道有BerkeleyDB這么一個東西，但第一次真正了解還是在Amazon的Dynamo那篇論文中提到過采用了BerkeleyDB作為單機(jī)上的底層存儲。當(dāng)時覺著這東西真另類，原來還有叫做“DB”的東西卻不支持SQL。那時候還沒有NOSQL這詞，把這樣的東西叫做non-relational database。
BerkeleyDB是一個key-value database，簡單的說，就是一個在disk上的hash表，這也是為什么它可以被用來做URL去重的原因。它另外一個另類的地方是，它是和程序運(yùn)行在同一個進(jìn)程空間中的，而不像一般的db，是做為單獨(dú)的程序運(yùn)行。
這里附上Heritrix中使用BerkeleyDB做URL去重的代碼，一探究竟：(代碼位于Heritrix源代碼的org.archive.crawler.util.BdbUriUniqFilter)
有一堆做初始化和配置的函數(shù)就直接忽略了，真正相關(guān)的函數(shù)就只有兩個：
[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;
}
}
簡單解釋一下：
第一個函數(shù)createKey是在做URL的壓縮，它將任意長度的URL轉(zhuǎn)換成一個long型的值。long型的取值范圍有2^64，因此兩個URL映射成同一個long型值的概率應(yīng)該挺低的。但我也沒太細(xì)看這個函數(shù)，所以它的效果到底如何不確定。
第二個函數(shù)setAdd就是將被壓縮的URL寫入到BerkeleyDB。之前說過，BerkeleyDB是一個key-value database，它的每條記錄都包括了一個key和一個value。但是在URL去重中，value不重要(比如我們之前內(nèi)存中用的也是HashSet而不是HashMap)，因此這里統(tǒng)一用一個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中已經(jīng)有了這個long型值，就會返回OperationStatus.KEYEXIST，表示對應(yīng)的URL之前已經(jīng)抓取到了，那么這個URL就不會放入待抓取隊列中。
最后
比較遺憾的是，我還沒抽出空對BerkeleyDB這個方案做性能測試，不確定它每秒能執(zhí)行多少次setAdd操作，是否足夠滿足我們性能的要求。以后補(bǔ)上。
另外，雖然我不了解，但我認(rèn)為像百度這樣專業(yè)的搜索引擎，它的爬蟲的URL去重方案可能比這里列舉的要復(fù)雜的多，畢竟那個的各方面的要求也要更高。
本回答由提問者推薦
已贊過
已踩過<
你對這個回答的評價是？
評論
收起
總結(jié)
以上是生活随笔為你收集整理的java dataurl_java url参数去重的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： java 链表算法_JAVA数据结构与算
- 下一篇： java抢答器代码_java竞争抢答器