GitHub仓库爬虫开发记录

因为要做一个Demo，数据源GitHub上所有Star过20的项目。但是呢，GitHub唉！拥有千万数量级别仓库的大型基佬交友社区唉！符合条件的就有33万条记录唉！所以就想把这次开发经历记录一下。想做到的最终目标是10个爬虫并发爬取项目；

爬虫的代码就不发了，网上一搜一大把，使用python3，用到的包有json、bs4、urllib；

2017年9月14日11点38分

爬虫开发记录：
开发进度：完成getRepo部分的框架
所遇问题：
1）GitHub search api 只能提供前1000条可访问记录；
2）GitHub api 对访问请求进行限制，对为验证请求提供10times/min，对验证请求提供30times/min；
解决方案：
1）I.缩小查询范围，可能存在的问题，导致仓库结果无序；
2）I.使用Basic Authentication, OAuth, or client ID and secret等方法进行验证，II.若使用并发爬虫导致请求量过大将使用python循环list解决（II待验证）

先记录到这里，下午对爬虫进行修改，解决search api的请求限制问题。

2017年9月19日14点33分

爬虫开发记录：

对于search api的提供限制问题，通过对stars范围进行切分，获得一组结果值小于等于1000的url列表。

关于2）I，在url后面添加&access_token=……

所遇问题：

当爬取每个库的stargazer时，会出现某一页卡死，程序不会继续向下run的情况；

2017年9月20日16点21分

所以目前针对以上提到的问题，我现在能想到的是使用多线程，差不多5~10个爬虫进行数据爬取，来提高爬取效率以及实现爬虫的超时重连。

2017年10月24日00点33分

关于之前的并发问题，发现如果直接使用scrapy爬仓库，不对速度加以限制的话，很容易就会让token“超速”，所以暂时还是老老实实的用自己婴幼版爬虫爬吧，等之后把scrapy吃透，可以自行定制的时候，可以用在beta版上；

在Linux不熟的时候遇到了一个很“神奇的”问题：“nohup command &”之后，退出远程连接后，再次连接时会出现command挂掉的情况。解决方案是，输入命令行之后，exit退出，而不是直接关闭连接。很神奇。感谢大佬

之后可以去尝试使用screen，据说功能比nohup强大得多。