接上篇，本篇談?wù)勔恍?shí)現(xiàn)細(xì)節(jié)。
這個(gè)爬蟲程序主要的問題在于如何獲取P2P網(wǎng)絡(luò)中分享的資源，獲取到資源后索引到數(shù)據(jù)庫中，搜索就是自然而然的事情。
DHT
DHT網(wǎng)絡(luò)本質(zhì)上是一個(gè)用于查詢的網(wǎng)絡(luò)，其用于查詢一個(gè)資源有哪些計(jì)算機(jī)正在下載。每個(gè)資源都有一個(gè)20字節(jié)長度的ID用于標(biāo)示，稱為infohash。當(dāng)一個(gè)程序作為DHT節(jié)點(diǎn)加入這個(gè)網(wǎng)絡(luò)時(shí)，就會有其他節(jié)點(diǎn)來向你查詢，當(dāng)你做出回應(yīng)后，對方就會記錄下你。對方還會詢問其他節(jié)點(diǎn)，當(dāng)對方開始下載這個(gè)infohash對應(yīng)的資源時(shí)，他就會告訴所有曾經(jīng)詢問過的節(jié)點(diǎn)，包括你。這個(gè)時(shí)候就可以確定，這個(gè)infohash對應(yīng)的資源在這個(gè)網(wǎng)絡(luò)中是有效的。
關(guān)于這個(gè)網(wǎng)絡(luò)的工作原理，參看：P2P中DHT網(wǎng)絡(luò)爬蟲以及寫了個(gè)磁力搜索的網(wǎng)頁。
獲取到infohash后能做什么？關(guān)鍵點(diǎn)在于，我們現(xiàn)在使用的磁力鏈接(magnet url)，是和infohash對應(yīng)起來的。也就是拿到infohash，就等于拿到一個(gè)磁力鏈接。但是這個(gè)爬蟲還需要建立資源的信息，這些信息來源于種子文件。種子文件其實(shí)也是對應(yīng)到一個(gè)資源，種子文件包含資源名、描述、文件列表、文件大小等信息。獲取到infohash時(shí)，其實(shí)也獲取到了對應(yīng)的計(jì)算機(jī)地址，我們可以在這些計(jì)算機(jī)上下載到對應(yīng)的種子文件。
但是我為了簡單，在獲取到infohash后，從一些提供映射磁力鏈到種子文件服務(wù)的網(wǎng)站上直接下載了對應(yīng)的種子。dhtcrawler里使用了以下網(wǎng)站：
http://torrage.com
https://zoink.it
http://bt.box.n0808.com
使用這些網(wǎng)站時(shí)，需提供磁力哈希（infohash可直接轉(zhuǎn)換），構(gòu)建特定的URL，發(fā)出HTTP請求即可。
U1 = "http://torrage.com/torrent/" ++ MagHash ++ ".torrent",
U2 = "https://zoink.it/torrent/" ++ MagHash ++ ".torrent",
U3 = format_btbox_url(MagHash),
format_btbox_url(MagHash) ->
H = lists:sublist(MagHash, 2),
T = lists:nthtail(38, MagHash),
"http://bt.box.n0808.com/" ++ H ++ "/" ++ T ++ "/" ++ MagHash ++ ".torrent".
但是，以一個(gè)節(jié)點(diǎn)的身份加入DHT網(wǎng)絡(luò)，是無法獲取大量查詢的。在DHT網(wǎng)絡(luò)中，每個(gè)節(jié)點(diǎn)都有一個(gè)ID。每個(gè)節(jié)點(diǎn)在查詢信息時(shí)，僅詢問離信息較近的節(jié)點(diǎn)。這里的信息除了infohash外還包含節(jié)點(diǎn)，即節(jié)點(diǎn)詢問一個(gè)節(jié)點(diǎn)，這個(gè)節(jié)點(diǎn)在哪里。DHT的典型實(shí)現(xiàn)中（Kademlia），使用兩個(gè)ID的xor操作來確定距離。既然距離的計(jì)算是基于ID的，為了盡可能獲取整個(gè)DHT網(wǎng)絡(luò)交換的信息，爬蟲程序就可以建立盡可能多的DHT節(jié)點(diǎn)，讓這些節(jié)點(diǎn)的ID均勻地分布在ID取值區(qū)間內(nèi)，以這樣的方式加入網(wǎng)絡(luò)。
在dhtcrawler中，我使用以下方式產(chǎn)生了N個(gè)大致均勻分布的ID：
create_discrete_ids(1) ->
[dht_id:random()];
create_discrete_ids(Count) ->
Max = dht_id:max(),
Piece = Max div Count,
[random:uniform(Piece) + Index * Piece || Index <- lists:seq(0, Count - 1)].
除了盡可能多地往DHT網(wǎng)絡(luò)里部署節(jié)點(diǎn)之外，對單個(gè)節(jié)點(diǎn)而言，也有些注意事項(xiàng)。例如應(yīng)盡可能快地將自己告訴盡可能多的節(jié)點(diǎn)，這可以在啟動(dòng)時(shí)進(jìn)行大量的隨機(jī)infohash的查詢。隨著查詢過程的深入，該節(jié)點(diǎn)會與更多的節(jié)點(diǎn)打交道。因?yàn)镈HT網(wǎng)絡(luò)里的節(jié)點(diǎn)實(shí)際上是不穩(wěn)定的，它今天在線，明天后天可能不在線，所以計(jì)算你的ID固定，哪些節(jié)點(diǎn)與你較近，本身就是個(gè)相對概念。節(jié)點(diǎn)在程序退出時(shí)，也最好將自己的路由信息（與自己交互的節(jié)點(diǎn)列表）保存起來，這樣下次啟動(dòng)時(shí)就可以更快地加入網(wǎng)絡(luò)。
在dhtcrawler的實(shí)現(xiàn)中，每個(gè)節(jié)點(diǎn)每個(gè)一定時(shí)間，都會向網(wǎng)絡(luò)中隨機(jī)查詢一個(gè)infohash，這個(gè)infohash是隨機(jī)產(chǎn)生的。其查詢目的不在于infohash，而在于告訴更多的節(jié)點(diǎn)，以及在其他節(jié)點(diǎn)上保持自己的活躍。
handle_event(startup, {MyID}) ->
timer:apply_interval(?QUERY_INTERVAL, ?MODULE, start_tell_more_nodes, [MyID]).
start_tell_more_nodes(MyID) ->
spawn(?MODULE, tell_more_nodes, [MyID]).
tell_more_nodes(MyID) ->
[search:get_peers(MyID, dht_id:random()) || _ <- lists:seq(1, 3)].
DHT節(jié)點(diǎn)的完整實(shí)現(xiàn)是比較繁瑣的，涉及到查詢以及繁雜的各種對象的超時(shí)（節(jié)點(diǎn)、桶、infohash），而超時(shí)的處理并不是粗暴地做刪除操作。因?yàn)楸旧硎腔赨DP協(xié)議，你得對這些超時(shí)對象做進(jìn)一步的查詢才能正確地進(jìn)一步做其他事情。而搜索也是個(gè)繁雜的事情，遞歸地查詢節(jié)點(diǎn)，感覺上，你不一定離目標(biāo)越來越近，由于被查詢節(jié)點(diǎn)的不確定性（無法確定對方是否在玩弄你，或者本身對方就是個(gè)傻逼），你很可能接下來要查詢的節(jié)點(diǎn)反而離目標(biāo)變遠(yuǎn)了。
在我第一次的DHT實(shí)現(xiàn)中，我使用了類似transmission里DHT實(shí)現(xiàn)的方法，不斷無腦遞歸，當(dāng)搜索有太久時(shí)間沒得到響應(yīng)后終止搜索。第二次實(shí)現(xiàn)時(shí)，我就使用了etorrent里的實(shí)現(xiàn)。這個(gè)搜索更聰明，它記錄搜索過的節(jié)點(diǎn)，并且檢查是否離目標(biāo)越來越遠(yuǎn)。當(dāng)遠(yuǎn)離目標(biāo)時(shí)，就認(rèn)為搜索是不太有效的，不太有效的搜索嘗試幾次就可以放棄。
實(shí)際上，爬蟲的實(shí)現(xiàn)并不需要完整地實(shí)現(xiàn)DHT節(jié)點(diǎn)的正常功能。爬蟲作為一個(gè)DHT節(jié)點(diǎn)的唯一動(dòng)機(jī)僅是獲取網(wǎng)絡(luò)里其他節(jié)點(diǎn)的查詢。而要完成這個(gè)功能，你只需要裝得像個(gè)正常人就行。這里不需要保存infohash對應(yīng)的peer列表，面臨每一次查詢，你隨便回復(fù)幾個(gè)節(jié)點(diǎn)地址就可以。但是這里有個(gè)責(zé)任問題，如果整個(gè)DHT網(wǎng)絡(luò)有2000個(gè)節(jié)點(diǎn)，而你這個(gè)爬蟲就有1000個(gè)節(jié)點(diǎn)，那么你的隨意回復(fù)，就可能導(dǎo)致對方根本找不到正確的信息，這樣你依然得不到有效的資源。（可以利用這一點(diǎn)破壞DHT網(wǎng)絡(luò)）
DHT的實(shí)現(xiàn)沒有使用第三方庫。
種子
種子文件的格式同DHT網(wǎng)絡(luò)消息格式一樣，使用一種稱為bencode的文本格式來編碼。種子文件分為兩類：單個(gè)文件和多個(gè)文件。
文件的信息無非就是文件名、大小。文件名可能包含utf8編碼的名字，為了后面處理的方便，dhtcrawler都會優(yōu)先使用utf8編碼。
{ok, {dict, Info}} = dict:find(<<"info">>, TD),
case type(Info) of
single -> {single, parse_single(Info)};
multi -> {multi, parse_multi(Info)}
end.
parse_single(Info) ->
Name = read_string("name", Info),
{ok, Length} = dict:find(<<"length">>, Info),
{Name, Length}.
parse_multi(Info) ->
Root = read_string("name", Info),
{ok, {list, Files}} = dict:find(<<"files">>, Info),
FileInfo = [parse_file_item(Item) || {dict, Item} <- Files],
{Root, FileInfo}.
數(shù)據(jù)庫
我最開始在選用數(shù)據(jù)庫時(shí)，為了不使用第三方庫，打算使用erlang自帶的mnesia。但是因?yàn)樯婕暗阶址ヅ渌阉?，mnesia的查詢語句在我看來太不友好，在經(jīng)過一些資料查閱后就直接放棄了。
然后我打算使用couchdb，因?yàn)樗莈rlang寫的，而我正在用erlang寫程序。第一次接觸非關(guān)系型數(shù)據(jù)庫，發(fā)現(xiàn)NoSQL數(shù)據(jù)庫使用起來比SQL類的簡單多了。但是在erlang里要使用couchdb實(shí)在太折騰了。我使用的客戶端庫是couchbeam。
因?yàn)閏ouchdb暴露的API都是基于HTTP協(xié)議的，其數(shù)據(jù)格式使用了json，所以couchbeam實(shí)際上就是對各種HTTP請求、回應(yīng)和json的包裝。但是它竟然使用了ibrowse這個(gè)第三方HTTP客戶端庫，而不是erlang自帶的。ibrowse又使用了jiffy這個(gè)解析json的庫。這個(gè)庫更慘烈的是它的解析工作都是交給C語言寫的動(dòng)態(tài)庫來完成，我還得編譯那個(gè)C庫。
couchdb看起來不支持字符串查詢，我得自己創(chuàng)建一個(gè)view，這個(gè)view里我通過翻閱了一些資料寫了一個(gè)將每個(gè)doc的name拆分成若干次查詢結(jié)果的map。這個(gè)map在處理每一次查詢時(shí)，我都得動(dòng)態(tài)更新之。couchdb是不支持局部更新的，這還不算大問題。然后很高興，終于支持字符串查詢了。這里的字符串查詢都是基于字符串的子串查詢。但是問題在于，太慢了。每一次在WEB端的查詢，都直接導(dǎo)致erlang進(jìn)程的call超時(shí)。
要讓couchdb支持字符串查詢，要快速，當(dāng)然是有解決方案的。但是這個(gè)時(shí)候我已經(jīng)沒有心思繼續(xù)折騰，任何一個(gè)庫、程序如果接口設(shè)計(jì)得如此不方便，那就可以考慮換一個(gè)其他的。
我選擇了mongodb。同樣的基于文檔的數(shù)據(jù)庫。2.4版本還支持全文搜索。什么是全文搜索呢，這是一種基于單詞的全文搜索方式。hello world我可以搜索hello，基于單詞。mongodb會自動(dòng)拆詞。更關(guān)鍵更讓人爽的是，要開啟這個(gè)功能非常簡單：設(shè)置啟動(dòng)參數(shù)、建立索引。沒了。mongodb的erlang客戶端庫mongodb-erlang也只依賴一個(gè)bson-erlang庫。然后我又埋頭苦干，幾個(gè)小時(shí)候我的這個(gè)爬蟲程序就可以在瀏覽器端搜索關(guān)鍵字了。
后來我發(fā)現(xiàn)，mongodb的全文搜索是不支持中文的。因?yàn)樗€不知道中文該怎么拆詞。恰好我有個(gè)同事做過中文拆詞的研究，看起來涉及到很復(fù)雜的算法。直到這個(gè)時(shí)候，我他媽才醒悟，我為什么需要基于單詞的搜索。我們大部分的搜索其實(shí)都是基于子字符串的搜索。
于是，我將種子文件的名字拆分成了若干個(gè)子字符串，將這些子字符串以數(shù)組的形式作為種子文檔的一個(gè)鍵值存儲，而我依然還可以使用全文索引，因?yàn)槿乃饕龝⒄麄€(gè)字符串作為單詞比較。實(shí)際上，基于一般的查詢方式也是可以的。當(dāng)然，索引還是得建立。
使用mongodb時(shí)唯一讓我很不爽的是mongodb-erlang這個(gè)客戶端庫的文檔太欠缺。這還不算大問題，因?yàn)榭纯丛创a參數(shù)還是可以大概猜到用法。真正悲劇的是mongodb的有些查詢功能它是不支持的。例如通過cursor來排序來限制數(shù)量。在cursor模塊并沒有對應(yīng)的mongodb接口。最終我只好通過以下方式查詢，我不明白batchsize，但它可以工作：
search_announce_top(Conn, Count) ->
Sel = {'$query', {}, '$orderby', {announce, -1}},
List = mongo_do(Conn, fun() ->
Cursor = mongo:find(?COLLNAME, Sel, [], 0, Count),
mongo_cursor:rest(Cursor)
end),
[decode_torrent_item(Item) || Item <- List].
另一個(gè)悲劇的是，mongodb-erlang還不支持文檔的局部更新，它的update接口直接要求傳入整個(gè)文檔。幾經(jīng)折騰，我可以通過runCommand來完成：
inc_announce(Conn, Hash) when is_list(Hash) ->
Cmd = {findAndModify, ?COLLNAME, query, {'_id', list_to_binary(Hash)},
update, {'$inc', {announce, 1}},
new, true},
Ret = mongo_do(Conn, fun() ->
mongo:command(Cmd)
end).
Unicode
不知道在哪里我看到過erlang說自己其實(shí)是不需要支持unicode的，因?yàn)檫@門語言本身是通過list來模擬字符串。對于unicode而言，對應(yīng)的list保存的本身就是整數(shù)值。但是為了方便處理，erlang還是提供了一些unicode操作的接口。
因?yàn)槲倚枰獙⒎N子的名字按字拆分，對于a中文這樣的字符串而言，我需要拆分成以下結(jié)果：
a
a中
a中文
中
中文
文
那么，在erlang中當(dāng)我獲取到一個(gè)字符串list時(shí)，我就需要知道哪幾個(gè)整數(shù)合起來實(shí)際上對應(yīng)著一個(gè)漢字。erlang里unicode模塊里有幾個(gè)函數(shù)可以將unicode字符串list對應(yīng)的整數(shù)合起來，例如：[111, 222, 333]可能表示的是一個(gè)漢字，將其轉(zhuǎn)換以下可得到[111222333]這樣的形式。
split(Str) when is_list(Str) ->
B = list_to_binary(Str), % 必須轉(zhuǎn)換為binary
case unicode:characters_to_list(B) of
{error, L, D} ->
{error, L, D};
{incomplete, L, D} ->
{incomplete, L, D};
UL ->
{ok, subsplit(UL)}
end.
subsplit([]) ->
[];
subsplit(L) ->
[_|R] = L,
{PreL, _} = lists:splitwith(fun(Ch) -> not is_spliter(Ch) end, L),
[unicode:characters_to_binary(lists:sublist(PreL, Len))
|| Len <- lists:seq(1, length(PreL))] ++ subsplit(R).
除了這里的拆字之外，URL的編碼、數(shù)據(jù)庫的存儲都還好，沒遇到問題。
注意，以上針對數(shù)據(jù)庫本身的吐槽，完全基于我不熟悉該數(shù)據(jù)庫的情況下，不建議作為你工具選擇的參考。
erlang的穩(wěn)定性
都說可以用erlang來編寫高容錯(cuò)的服務(wù)器程序。看看它的supervisor，監(jiān)視子進(jìn)程，自動(dòng)重啟子進(jìn)程。天生的容錯(cuò)功能，就算你宕個(gè)幾次，單個(gè)進(jìn)程自動(dòng)重啟，整個(gè)程序看起來還穩(wěn)健地在運(yùn)行，多牛逼啊。再看看erlang的進(jìn)程，輕量級的語言特性，就像OOP語言里的一個(gè)對象一樣輕量。如果說使用OOP語言寫程序得think in object，那用erlang你就得think in process，多牛逼多駭人啊。
實(shí)際上，以我的經(jīng)驗(yàn)來看，你還得以傳統(tǒng)的思維去看待erlang的進(jìn)程。一些多線程程序里的問題，在erlang的進(jìn)程環(huán)境中依然存在，例如死鎖。
在erlang中，對于一些異步操作，你可以通過進(jìn)程間的交互將這個(gè)操作包裝成同步接口，例如ping的實(shí)現(xiàn)，可以等到對方回應(yīng)之后再返回。被阻塞的進(jìn)程反正很輕量，其包含的邏輯很單一。這不但是一種良好的包裝，甚至可以說是一種erlang-style。但這很容易帶來死鎖。在最開始的時(shí)候我沒有注意這個(gè)問題，當(dāng)爬蟲節(jié)點(diǎn)數(shù)上升的時(shí)候，網(wǎng)絡(luò)數(shù)據(jù)復(fù)雜的時(shí)候，似乎就出現(xiàn)了死鎖型宕機(jī)（進(jìn)程互相等待太久，直接timeout）。
另一個(gè)容易在多進(jìn)程環(huán)境下出現(xiàn)的問題就是消息依賴的上下文改變問題。當(dāng)投遞一個(gè)消息到某個(gè)進(jìn)程，到這個(gè)消息被處理之前，這段時(shí)間這個(gè)消息關(guān)聯(lián)的邏輯運(yùn)算所依賴的上下文環(huán)境改變了，例如某個(gè)ets元素不見了，在處理這個(gè)消息時(shí)，你還得以多線程編程的思維來編寫代碼。
至于supervisor，這玩意你得端正態(tài)度。它不是用來包容你的傻逼錯(cuò)誤的。當(dāng)你寫下傻逼代碼導(dǎo)致進(jìn)程頻繁崩潰的時(shí)候，supervisor屁用沒有。supervisor的唯一作用，僅僅是在一個(gè)確實(shí)本身可靠的系統(tǒng)，確實(shí)人品問題萬分之一崩潰了，重啟它。畢竟，一個(gè)重啟頻率的推薦值，是一個(gè)小時(shí)4次。