闲暇时间看了下DHT网络

根据实际的测试效果来看，当收集的资源量过百万时（目前bt.cm录入近160万资源），4G内存的Windows平台，mongodb很容易就会挂掉。挂掉的原因全是1455，页面文件太小。有人建议不要在Windows下使用mongodb，Linux下我自己没做过测试。


mongodb可以部署为集群形式(replica-set)，当初我想把http部分的查询放在一个只读的mongodb实例上，但因为建立集群时，要同步已有的10G数据库，而每次同步都以mongodb挂掉结束，遂放弃。在目前bt.cm的配置中，数据库torrent的锁比例（db lock）很容易上50%，这也让http在搜索时，经常出现搜索超时的情况。
关于这个网络的工作原理，参看： P2P中DHT网络爬虫以及写了个 磁力搜索的网页。
找了台服务器将磁力链接爬虫架设起来 http://www.51bt.cc(51搜索)大家可以看下。
效果可以看下具体51搜索展示 http://www.51bt.cc，结合Xunsearch全文检索技术，可以达到毫秒级的数据搜索

技术信息


dhtcrawler最早的版本有很多问题，修复过的最大的一个问题是关于erlang定时器的，在DHT实现中，需要对每个节点每个peer做超时处理，在erlang中的做法直接是针对每个节点注册了一个定时器。这不是问题，问题在于定时器资源就像没有GC的内存资源一样，是会由于程序员的代码问题而出现资源泄漏。所以，dhtcrawler第一个版本在节点数配置在100以上的情况下，用不了多久就会内存耗尽，最终导致erlang虚拟机core dump。


除了这个问题以外，dhtcrawler的资源收录速度也不是很快。这当然跟数据库和获取种子的速度有直接关系。尤其是获取种子，使用的是一些提供info-hash到种子映射的网站，通过HTTP请求来下载种子文件。我以为通过BT协议直接下载种子会快些，并且实时性也要高很多，因为这个种子可能未被这些缓存网站收录，但却可以直接向对方请求得到。为此，我还特地翻阅了相关协议，并且用erlang实现了（以后的文章我会讲到具体实现这个协议）。


后来我怀疑get_peers的数量会不会比announce_peer多，但是理论上一般的客户端在get_peers之后都是announce_peer，但是如果get_peers查询的peers恰好不在线呢？这意味着很多资源虽然已经存在，只不过你恰好暂时请求不到。实际测试时，发现get_peers基本是announce_peer数量的10倍。


将hash的获取方式做了调整后，dhtcrawler在几分钟以内以几乎每秒上百个新增种子的速度工作。然后，程序挂掉。


从dhtcrawler到今天为止的dhtcrawler2，中间间隔了刚好1个月。我的所有业余时间全部扑在这个项目上，面临的问题一直都是程序的内存泄漏、资源收录的速度不够快，到后来又变为数据库压力过大。每一天我都以为我将会完成一个稳定版本，然后终于可以去干点别的事情，但总是干不完，目前完没完都还在观察。我始终明白在做优化前需要进行详尽的数据收集和分析，从而真正地优化到正确的点上，但也总是凭直觉和少量数据分析就开始尝试。


这里谈谈遇到的一些问题。