世界上已经有了这么多种子搜索引擎,为什么你还要不厌其烦的做一个新的?
可以这么说,地球上大多数的种子搜索引擎的前后端技术都比较古老,虽然古老的技术既经典又好用,但是作为一个喜欢尝鲜的人,我仍然决定使用目前最为先进的开发技术制作一个功能简明的种子搜索引擎。
采用了什么技术?
前端:在vue,angular,react三大现代开发框架中选择了vue,做出这个决定的原因也仅仅是一直以来对vue的谜之好感。有时候就是这样,缘分到了不得不从,恰巧nuxtjs在9月更新了2.0,因此毫不犹豫选择了vue。
后端:在koa,gin,springboot中权衡良久,由于很长时间没有写过java,最后选择了springboot + jdk11,用写javascript的感觉来写java,还是很不错的。从追求速度上来讲,可能使用gin或Koa要更快,但是这一点提升对于我这种实验性网站来说,意义并不是很大。
全文检索:尝试了全文检索里面的比较潮的couchbase、redissearch、elasticsearch,最后选定elasticsearch,另外两个的速度虽然远高于elasticsearch,但毕竟是内存式数据库,简单功能尚可,复杂度上去后则吃内存太多。
制作过程呢?
下面我分享下大概过程,涉及到复杂原理,请自行谷歌,我不认为我可以把复杂原理描述的很简单。
关于命名:
从手中的十来个域名选择了
中国国内同名的网站有几个,但是这不是问题。
关于服务器:
几经周折,购买了一台美国服务器。配置是: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
唯一不妥是运行一段时间(