起因
学习爬虫爬取数据,不可避免就是爬虫与反爬虫的对抗.
使用代理ip作为一种反爬虫的方式还是比较有效的.
在做爬取代理ip项目之前,也搜索了一些相关的项目.qiye的项目还是很不错的.但在使用中也出现了一些问题.例如偶尔被个别代理网站封ip(某段时间内重启程序过多吧)等.
scrapy使用qiye的项目时,经常出现10060和10061的错误,以及超时等错误,导致不停的刷代理池中的代理ip.为了解决这个问题,考虑过两种方法:
1.更改scrapy的代码,使用代理时不成功重启一次request.记得有的错误,scrapy不会重启一次request.
2.确保代理ip的有效性.
方法2更适合一些.scrapy就应该专注于爬取网站.方法2也是在源头上保证了代理ip的有效性.
嗯.意味着自己重写一个爬取代理ip的项目.
项目设计与实现
刚开始想法比较简单,直接实现一个代理ip的抓取,验证,存储,获取.与qiye的项目大体类似的功能即可.在代理网站上获取代理ip,验证url后,存放sqlite,然后通过请求web api返回代理ip.
问题来了:
1.目标网站为douban[虽然豆瓣上有api,但是api不满足我的需求,只能自己爬豆瓣了],相当于测试代理ip要骗过豆瓣的反爬虫设置.豆瓣反爬虫最重要的一个东西就是带cookie访问.这个cookie也可以随机仿造.
2.sqlite本身是轻量级的数据库.单进程/线程访问没问题,并发访问时需要自己构建锁保护,感觉使用sqlite比较low,使用mysql等又感觉没必要.qiye的项目中用到了sqlalchemy,支持各种数据库.个人感觉没必要,因为作为一个辅助类 小项目,定位就是小,轻.能够快速返回用户代理ip即可.
3.在测试豆瓣和豆瓣api过程中遇到的坑,就是对豆瓣api使用代理ip基本无效.代理ip爬豆瓣还好,但是通过代理ip突破豆瓣api分钟限制,代理ip全是失败,很少成功.估计豆瓣api那里对反爬设置更严格一些,使用高匿的代理ip才可以.但实际上高匿的ip很少,代理网站上说是高匿,不一定就是高匿.
P.S.关于豆瓣的问题,cookie里面需要设置两项才可以，不然容易被ban。不是ip的问题。其实这个也说明一个问题，需要对爬取网站的一些机制有一定了解，多尝试。
4.数据库中数据存储多了,一个进程处理不完,会被淹没.
5.各种细节问题.
设计/实现
1.使用了bloomfilter进行判重.获取的代理ip可能之前有判定重复的,通过检查判重,减少资源消耗.每隔一定时间bf会被清空.
python本身自带bf,当时好像遇到什么问题了,实际使用与需求有点不符,具体记不清楚了,最后摒弃了自带的bf,使用了别人的一个bf on redis的项目.paramiao/pydrbloomfilter
其实我就是想用用bf而已.造轮子花费时间,就暂时不造了.
2.目标网站检测使用的反爬虫方式:
代理ip[废话,测试用] 随机agent 带cookie访问.
3.多进程进行ip判定.防止数量太多进程一直运行.目前判定进程数是直接配置在配置文件中的,后面想做到自适应.
4.代理ip通过轮询的方式给出.后续想更新算法,根据时间与计数挑选
5.web端做了一层缓存,挑选一定数量的ip,每隔2-3分钟,进行检测,这个检测就不需要是爬取的网站的url,因为测试过能够连接代理访问即可,例如baidu之类的比较大众的网站.
6.数据库使用redis.redis这里作为两点,一个是数据存储,一个是web的缓存.而且redis本身又不是很大.用在这里很适合.而且bf-redis项目中,也在使用redis.
7.已经实现为多个目标网站提供不同的代理,以及提供不同的缓存.
TODO
后续会做一些改进.大的方面有以下几点
1.更改代理ip选举算法.
2.检测进程自适应.
3.修改程序问题。时间久了有些进程会有问题，可能跟gevent有关。有时间了再完善找原因吧。在搞M.L.
如有疑问,留言或私信......
