用elasticsearch和nuxtjs搭建bt搜索引擎
可以這麽說，地球上大多數的種子搜索引擎的前後端技術都比較古老，雖然古老的技術既經典又好用，但是作為一個喜歡嘗鮮的人，我仍然決定使用目前最為先進的開發技術制作一個功能簡明的種子搜索引擎。
采用了什麽技術？
前端：在vue,angular,react三大現×××發框架中選擇了vue，做出這個決定的原因也僅僅是一直以來對vue的謎之好感。有時候就是這樣，緣分到了不得不從，恰巧nuxtjs在9月更新了2.0，因此毫不猶豫選擇了vue。
後端：在koa,gin,springboot中權衡良久，由於很長時間沒有寫過java，最後選擇了springboot + jdk11，用寫javascript的感覺來寫java，還是很不錯的。從追求速度上來講，可能使用gin或Koa要更快，但是這一點提升對於我這種實驗性網站來說，意義並不是很大。
制作過程呢？
下面我分享下大概過程，涉及到復雜原理，請自行谷歌，我不認為我可以把復雜原理描述的很簡單。
關於命名：
從手中的十來個域名選擇了
btzhai.top
中國國內同名的網站有幾個，但是這不是問題。
關於服務器：
幾經周折，購買了一臺美國服務器。配置是:E5-1620|24G|1TB|200M帶寬，真正的24小時人工服務。考慮到要用cloudfare，所以不需要硬防。一月1200RMB。
在此期間嘗試了很多家服務器，深感這免備案服務器這一行真的是泥沙俱下。
關於爬蟲：
大約8月初終於有空來著手bt搜索引擎這件事情。
首先擺在我面前的問題就是數據來源問題，要知道所謂的dht網絡，說白了就是一個節點既是服務器又是客戶端，你在利用dht網絡下載時會廣播到網絡中，別的節點就會接收到你所下載文件的唯一標識符infohash（有的地方稱之為神秘代碼）和metadata，這裏面包括了這個文件的名稱、大小、創建時間、包含文件等信息，利用這個原理，dht爬蟲就可以收集dht網絡中的即時熱門下載。
如果僅僅依靠依靠dht爬蟲去爬的話，理論上初期速度大約為40w一天，30天可以收集上千萬，但是dht網絡裏面的節點不可能總是下載新的文件，現實情況是：大多數情況下冷門的種子幾年無人問津，熱門種子天天數十萬人下載。可以推想，隨著種子基數增加，重復的infohash會越來越多，慢慢地只會增加所謂的種子熱度而不會增加基數，但是沒有1000w+的種子，從門面上來講不好看。
去哪裏弄1000w種子成了當時我主要研究的問題。首先我從github上選取了幾個我認為比較好用的dht爬蟲進行改造，讓之可以直接將數據入庫到elasticsearch中，並且在infohash重復的時候自動對熱度+1。
elasticsearch的mapping如下，考慮到中文分詞，選用了smartcn作為分詞器，當然ik也是可以的。種子內的文件列表files，本來設置為nested object，因為nested query性能不高已經取消:
{
"properties": {
"name": {
"type": "text",
"analyzer": "smartcn",
"search_analyzer": "smartcn"
},
"length": {
"type": "long"
},
"popularity": {
"type": "integer"
},
"create_time": {
"type": "date",
"format": "epoch_millis"
},
"files": {
"properties": {
"length": {
"type": "long"
},
"path": {
"type": "text",
"analyzer": "smartcn",
"search_analyzer": "smartcn"
}
}
}
}
}服務器上開始24小時掛著dht爬蟲。期間我也嘗試過多種不同語言的開源爬蟲來比較性能，甚至還找人試圖購買bt種子。下面這些爬蟲我都實際使用過：
https://github.com/shiyanhui/dht
https://github.com/fanpei91/p2pspider
https://github.com/fanpei91/simDHT
https://github.com/keenwon/antcolony
https://github.com/wenguonideshou/zsky然而這些dht爬蟲經試驗，或多或少都有些問題，有的是只能采集infohash而不能采集metadata，有的采集速度不夠，有的則隨時間增加資源占用越來越大。
最終確定的是這個最優解：
https://github.com/neoql/btlet唯一不妥是運行一段時間（大約10個小時）後就會崩潰退出，可能跟采集速度有關。而在我寫這篇文章的前幾天，作者稱已經將此問題修復，我還沒有來得及跟進更新。可以說這是我實驗過采集速度最快的dht爬蟲。有興趣的同學可以去嘗試、PR。
爬蟲正常化運行以後，我終於發現了基數問題的解決之道，那就是skytorrent關閉後dump出來的數據庫和openbay，利用這大約4000w infohash數據和bthub，每天都一定可以保證有數萬新的metadata入庫。
關於bthub我要說的是，api請求頻率太高會被封ip，發郵件詢問的結果如下。經過我的反復測試，api請求間隔設為1s也是沒問題的：
關於前端：
我比較習慣於先畫出簡單的前端再開始寫後端，前端確定清楚功能以後就可以很快寫出對應的接口。bt搜索引擎目前具有以下這麽幾個功能就足夠了：
-
可以搜索關鍵詞
-
首頁可以展現之前搜索過的排行前十的關鍵詞
-
可以隨機推薦一些文件
- 可以按照相關性、大小、創建時間、熱度排序
首頁啟動時，為了提高速度，從後臺讀cache，包括收錄了多少infohash、隨機推薦的文件名稱、搜索關鍵詞top10等等，這些cache使用@Scheduled每天自動更新一次。
點擊搜索後，跳轉到結果展現頁面，這裏只展現elasticsearch處理過highlight之後的結果而不展現所有原始結果，每頁展示10個結果。
原始結果的展現放在最後一個詳細畫面上。
前端承載的另一個重要問題就是seo，這也是我使用nuxtjs的原因。前端功能完成以後，我為它添加了meta描述、google analytics、百度。
sitemap的添加倒是耗廢了一些時間，因為是動態網頁的緣故，只能用nuxt-sitemap來動態生成。
另外用媒體查詢和vh、vw做了移動適配。不敢說100%，至少可以覆蓋90%的設備。
關於後端：
spring data在實現核心搜索api時遇到了問題，核心搜索如果寫成json，舉個例子的話，可能是下面的這個樣子：
{
"from": 0,
"size": 10,
"sort": [{
"_score": "desc"
}, {
"length": "desc"
}, {
"popularity": "desc"
}, {
"create_time": "desc"
}],
"query": {
"multi_match": {
"query": "這裏是要搜索的關鍵詞",
"fields": ["name", "files.path"]
}
},
"highlight": {
"pre_tags": ["<strong>"],
"post_tags": ["</strong>"],
"fields": {
"name": {
"number_of_fragments": 1,
"no_match_size": 150
},
"files.path": {
"number_of_fragments": 3,
"no_match_size": 150
}
}
}
}highlight返回的結果將沒有辦法自動和entity匹配，因為這一部分數據不在source中，spring data無法通過getSourceAsMap來獲取。這裏需要用到NativeSearchQueryBuilder去手動配置，如果有更好的方式，請務必賜教。java代碼如下:
var searchQuery = new NativeSearchQueryBuilder()
.withIndices("torrent_info").withTypes("common")
.withQuery(QueryBuilders.multiMatchQuery(param.getKeyword(), "name", "files.path"))
.withHighlightFields(new HighlightBuilder.Field("name").preTags("<strong>").postTags("</strong>").noMatchSize(150).numOfFragments(1), new HighlightBuilder.Field("files.path").preTags("<strong>").postTags("</strong>").noMatchSize(150).numOfFragments(3))
.withPageable(PageRequest.of(param.getPageNum(), param.getPageSize(), sort))
.build();
var torrentInfoPage = elasticsearchTemplate.queryForPage(searchQuery, TorrentInfoDo.class, new SearchResultMapper() {
@SuppressWarnings("unchecked")
@Override
public <T> AggregatedPage<T> mapResults(SearchResponse searchResponse, Class<T> aClass, Pageable pageable) {
if (searchResponse.getHits().getHits().length <= 0) {
return null;
}
var chunk = new ArrayList<>();
for (var searchHit : searchResponse.getHits()) {
// 設置info部分
var torrentInfo = new TorrentInfoDo();
torrentInfo.setId(searchHit.getId());
torrentInfo.setName((String) searchHit.getSourceAsMap().get("name"));
torrentInfo.setLength(Long.parseLong(searchHit.getSourceAsMap().get("length").toString()));
torrentInfo.setCreate_time(Long.parseLong(searchHit.getSourceAsMap().get("create_time").toString()));
torrentInfo.setPopularity((Integer) searchHit.getSourceAsMap().get("popularity"));
// ArrayList<Map>->Map->FileList->List<FileList>
var resList = ((ArrayList<Map>) searchHit.getSourceAsMap().get("files"));
var fileList = new ArrayList<FileList>();
for (var map : resList) {
FileList file = new FileList();
file.setPath((String) map.get("path"));
file.setLength(Long.parseLong(map.get("length").toString()));
fileList.add(file);
}
torrentInfo.setFiles(fileList);
// 設置highlight部分
// 種子名稱highlight(一般只有一個)
var nameHighlight = searchHit.getHighlightFields().get("name").getFragments()[0].toString();
// path highlight列表
var pathHighlight = getFileListFromHighLightFields(searchHit.getHighlightFields().get("files.path").fragments(), fileList);
torrentInfo.setNameHighLight(nameHighlight);
torrentInfo.setPathHighlight(pathHighlight);
chunk.add(torrentInfo);
}
if (chunk.size() > 0) {
// 不設置total返回不了正確的page結果
return new AggregatedPageImpl<>((List<T>) chunk, pageable, searchResponse.getHits().getTotalHits());
}
return null;
}
});關於elasticsearch:
種子搜索不需要多高的實時性，一臺服務器也不需要副本，因此，index的設置都是這樣：
{
"settings": {
"number_of_shards": 2,
"number_of_replicas": 0,
"refresh_interval": "90s"
}
}jvm配置了8G內存，G1GC，另外還禁了swapping：
## IMPORTANT: JVM heap size
-Xms8g
-Xmx8g
## GC configuration
-XX:+UseG1GC
-XX:MaxGCPauseMillis=50運行得怎麽樣？
由於搜索比較復雜，平均搜索時間1s左右，搜索命中上百萬數據時會大於2s。
下面是cloudfare的統計：
用elasticsearch和nuxtjs搭建bt搜索引擎