filter只能過濾兩種URL Pattern /xxxx/*或者*.， 不支持樓主這樣的模式, 實現(xiàn)過濾add請求，最好寫成/add/xxxx
成都創(chuàng)新互聯(lián)主要從事成都網(wǎng)站建設、網(wǎng)站制作、網(wǎng)頁設計、企業(yè)做網(wǎng)站、公司建網(wǎng)站等業(yè)務。立足成都服務江漢,十余年網(wǎng)站建設經(jīng)驗,價格優(yōu)惠、服務專業(yè),歡迎來電咨詢建站服務:18980820575
言歸正傳。
所謂的Url去重（我一直沒找到對應的英文，URL Filtering ?），就是爬蟲將重復抓取的URL去除，避免多次抓取同一網(wǎng)頁。爬蟲一般會將待抓取的URL放在一個隊列中，從抓取后的網(wǎng)頁中提取到新的URL，在他們被放入隊列之前，首先要確定這些新的URL沒有被抓取過，如果之前已經(jīng)抓取過了，就不再放入隊列。
最直觀的做法 – hash表
為了盡快把整個爬蟲搭建起來，最開始的URL去重采用方案是一個內(nèi)存中的HashSet，這是最直觀的方法，所有人都能想得到。HashSet中放置的就是URL的字符串，任何一個新的URL首先在HashSet中進行查找，如果HashSet中沒有，就將新的URL插入HashSet，并將URL放入待抓取隊列。
這個方案的好處是它的去重效果精確，不會漏過一個重復的URL。它的缺點是，我的爬蟲第二天早上就掛了，Out Of Memory。因為隨著抓取網(wǎng)頁的增加，HashSet會一直無限制的增長。另外，網(wǎng)絡中的很多URL其實是很長的，有大量的URL長度達到上百個字符。當然，因為我的爬蟲是跑在一個小服務器上，JVM的內(nèi)存本來就不多，否則它應該能再多撐1-2天。
簡單估算一下，假設單個URL的平均長度是100 byte（我覺著這已經(jīng)非常保守了），那么抓取1000萬的URL就需要：
100 byte * 10 000 000 = 1 GB
而1000萬URL在整個互聯(lián)網(wǎng)中實在是滄海一粟?？梢粤私?，需要多大的內(nèi)存才能裝下所有URL的HashSet。
壓縮URL
為了我的爬蟲能再多撐幾天，同時不想改動太多的代碼，第二個版本增加了一個小功能，就是HashSet中不存儲原始的URL，而是將URL壓縮后再放進去。貌似有不少paper中討論過如何對URL進行壓縮，包括新浪微博中的短URL其實也是個不錯的方案，可惜這些方法我都不會。為了偷懶，我直接用MD5對URL做編碼。
MD5的結(jié)果是128 bit也就是16 byte的長度。相比于之間估計的URL平均長度100byte已經(jīng)縮小了好幾倍，可以多撐好多天了。
當然，哪怕找個一個可以壓縮到極致的算法，隨著URL越來越多，終有一天會Out Of Memory。所以，這個方案不解決本質(zhì)問題。
MD5另外一個問題是，有可能兩個相同的URL被映射成同一個MD5值，這樣的話，它們中有一個就永遠不會被抓取了。我不太確定的是，這個概率會有多大。如果非常小的話，這微小的誤差倒也不會有太大影響。
Bloom Filter
基于內(nèi)存的HashSet的方法存在一個本質(zhì)的問題，就是它消耗的內(nèi)存是隨著URL的增長而不斷增長的。除非能夠保證內(nèi)存的大小能夠容納下所有需要抓取的URL，否則這個方案終有一天會到達瓶頸。
這時候就會想，要找一個類似于HashSet的但所消耗的內(nèi)存相對固定而不會不斷增長的方案，于是自然想到了Bloom Filter。關于Bloom Filter的概念這里就不多談了，網(wǎng)上隨處可以找到。我簡單嘗試了一下Bloom Filter，但是很快就放棄了?；贐loom Filter的方案有幾個問題：
第一個是理論上的。Bloom Filter會將一些正常的樣本（在我這就是沒有抓取過的URL）過濾掉，即所謂的False Positive。當然，這概率有多大，取決于Bloom Filter的參數(shù)設置。但這引出了下一個問題；
第二個是實踐中的，即Bloom Filter的那幾個參數(shù)應該如何設置？m，k，n應該設置成多少才合適，這個我沒有經(jīng)驗，而且可能需要反復的實驗和測試才能夠比較好的確定下來；
以上兩個問題還不是我放棄Bloom Filter的根本原因，真實的原因是我在做的是一個爬蟲框架，上面可以會啟動很多的爬蟲任務，每個任務可能抓取自己特定的URL，而且任務之間是獨立的。這樣，對于每個任務都需要有一個Bloom Filter，雖然對于單一任務它使用Bloom Filter所消耗的內(nèi)存是固定的，但是任務的增多會導致更多的Bloom Filter，從而導致更多的內(nèi)存消耗。仍然存在內(nèi)存溢出的可能。
但如果只是一個抓取任務，那么采用Bloom Filter應該是一個非常不錯的選擇。
BerkeleyDB
我終于明白我所需要的其實是一個可以放在disk上的去重方案，這樣，內(nèi)存溢出將永遠成不了可能。很早就知道有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）
有一堆做初始化和配置的函數(shù)就直接忽略了，真正相關的函數(shù)就只有兩個：
[java] view plaincopy
/**
* Create fingerprint.
* Pubic access so test code can access createKey.
* @param uri URI to fingerprint.
* @return Fingerprint of passed codeurl/code.
*/
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型值的概率應該挺低的。但我也沒太細看這個函數(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，表示對應的URL之前已經(jīng)抓取到了，那么這個URL就不會放入待抓取隊列中。
最后
比較遺憾的是，我還沒抽出空對BerkeleyDB這個方案做性能測試，不確定它每秒能執(zhí)行多少次setAdd操作，是否足夠滿足我們性能的要求。以后補上。
另外，雖然我不了解，但我認為像百度這樣專業(yè)的搜索引擎，它的爬蟲的URL去重方案可能比這里列舉的要復雜的多，畢竟那個的各方面的要求也要更高。
不知道你說的是什么意思，你可以吧數(shù)據(jù)加在url上一起發(fā)送，在filter中用request.getParameter(“數(shù)據(jù)名稱”)獲得，request要轉(zhuǎn)為HttpServletRequest
在web.xml里面配置，如下：
filter
filter-nameFileUploadFilter/filter-name
filter-classcom.ckfinder.connector.FileUploadFilter/filter-class
init-param
param-namesessionCookieName/param-name
param-valuejsessionid/param-value
/init-param
init-param
param-namesessionParameterName/param-name
param-valueJSESSIONID/param-value
/init-param
/filter
filter-mapping
filter-nameFileUploadFilter/filter-name
url-pattern/plug-in/ckfinder/core/connector/java/connector.java/url-pattern
/filter-mapping
有一個filter 和一個filter-mapping
你說的意思是servlet吧 新建立servlet 可以如此實現(xiàn) 不過現(xiàn)在流行 后綴。do 的形式
具體代碼如下
servlet
servlet-nameXFireServlet/servlet-name
servlet-classorg.codehaus.xfire.transport.http.XFireConfigurableServlet/servlet-class
load-on-startup0/load-on-startup
/servlet
servlet-mapping
servlet-nameXFireServlet/servlet-name
url-pattern/services/*/url-pattern
/servlet-mapping
重慶分公司
重慶分公司
