scrapy redis 增量爬虫

各种技术贴满满的copy, paste味道,真遇到实际问题却很少提及,比如最常见的增量爬虫。scrapy redis在第一次爬取时可以用自带的驱虫中间件,但是增量爬虫不行,这里我写了个中间件可以实现增量爬取,前提是目标url会变化。如果是url不变但是网页内容变化的增量爬虫,就需要新的解决方案了。

虽然配合redis,scrapy理论上可以暂停重启,但是有时候程序可能有问题一次ctrl c无法停止,强制两次ctrl C又会破坏scrapy redis的重启机制。很多时候dupefilter里的url指纹和mysql数据库里的url可能不一致,甚至有些情况下你必须清空dupefilter重新运行爬虫(强制停止爬虫时很多requests虽然没有爬取成功但是指纹却放到了dupefilter,下一次爬取时就会忽略这些url),这个中间件就能解决你的问题。

方案很简单,就是从mysql读取所有的url放到redis,每次request之前都会检查下所要请求的url是否已经爬取了,redis比mysql效率高很多,非常适合这种秒级应用。另外,如果url很多,可以用md5来节省redis内存,这里没有用,很容易实现。

class DedupeMiddleware(object): # 定制去重中间件

    logger = logging.getLogger(__name__) # 利用这个可以方便进行scrapy 的log输出
    client = redis.Redis(host=settings.REDIS_HOST, port=6379, db=0, password=settings.REDIS_PWD)
    if client:
        logger.info('redis connected for dedupe')
    else:
        logger.info('redis connect failed for dedupe') 

    def process_request(self, request, spider):
        # Called for each request that goes through the downloader
        # middleware.

        # Must either:
        # - return None: continue processing this request
        # - or return a Response object
        # - or return a Request object
        # - or raise IgnoreRequest: process_exception() methods of
        #   installed downloader middleware will be called
        if self.client.hexists('existing_url', request.url): #取item里的url和key里的字段对比,看是否存在,存在就丢掉这个item。不存在返回item给后面的函数处理
            self.logger.info(f'{request.url} already in mysql')
            raise IgnoreRequest(f'{request.url} already in mysql')
        return None

scrapy-redis搭配splash全站爬虫

上一次爬取BOSS直聘,我高调地在领英上发了几个帖子,结果招来了BOSS直聘一个高管的访问,还好我只爬了100多万职位数据,每天最多爬取8-10万,估计没有给对方服务器带来太大压力,不然我可能因为一时兴起惹了麻烦。

爬取BOSS直聘时我是自建的框架,最关键的突破当然是跨越了selenium阻塞影响并发这道坎儿。实际上,很多情况下设置下Desired_Capability中的page_load policy为’None’,selenium几乎就成了非阻塞了。当然,这个小秘密初学者一般不知道,大都会抱怨selenium的慢。我测试过,采用这种策略,不到1秒就能返回页面数据,印象中应该是几十到几百毫秒吧。

即便如此,我还是没能完美解决selenium超时这个问题,毕竟是模拟浏览器,它在超时的时候往往会停止响应,阻塞下面的流程,怎么设置timeout参数都没用。后来我发现,多进程会稳定很多,多线程timeout带来的阻塞问题在多进程并不是太大的问题,一是线程独立,挂掉一个互不影响,二是如果真的阻塞了可以根据pid来杀死进程重启。当然,我没有用scrapy搭配selenium,以后有机会可以试试。

BOSS直聘的反爬还是有点水平的,主要是它很容易弹出验证码。我用过多贝云和阿布云的隧道代理,两家质量差不多,都不错,只是动态版的IP响应速度会慢一些。问题是每个IP用在BOSS直聘效果不一样,有的估计之前被人用过所以第一次就被BOSS黑了,好点的话一般短时间内爬取好像20页问题不大。当然我还用ADSL自建过代理池,效果一般,主要是ADSL主机只有两个,池子小了容易造成程序等待IP代理。

这次爬取拉勾网,我才用了新的框架,scrapy-redis-splash,研究了几天就上手了。说实话,写这种程序和平时处理分析地震数据思维是一样的,只是工具不同而已。找出问题-问题分解-解决问题,都是这么一个思路。总结下这个框架吧。

  1. scrapy: 成熟框架,容易上手,但是因为是框架,需要多读文档多读源码才行,不是自建的轮子用起来不是很顺手,毕竟不能控制主循环。
  2. redis:因为之前做代理池就用过,这次用起来也很顺手。redis去重和调度并不像文档说的那么简单,比如爬虫重启时会有个问题,硬重启需要删除之前的requests,问题是之前的url虽然爬取过进了dupefilter,但是并没有成功爬取Item,重启后这些就会被过滤了。这个应该不难解决,我有时间看看源码。
  3. splash。这个才是重头戏,splash有个问题就是不释放内存,即使我的笔记本有32G内存也会很快被耗尽,虽然代码中我做了内存监控重启docker,也不是很完美。这个还是小问题,代码中可以监控或者启动docker时限制内存使用即可,大问题是504 gateway timeout,官方文档中和网络上说的设置一个很大的timeout实际上不好使,504照样还是很多,而且我发现只要是504就会阻塞,设置过大了程序有时就卡住了,太小了504就更多。504告诉我们的实际上就是splash没能及时渲染出网页,这个的终极解决方案是HAproxy做一个load balancer,用多个docker instance(2G内存一个都可以),甚至自己的笔记本都能并发多个实例。这里我用了Acquarium, github上有,Acquarium唯一的坑就是在Docker for windows下你可能无法登录8036那个监控页面,这里涉及到了Docker和宿主机的网络问题,比较复杂,启用ubuntu WSL2 backend就好了,然后就能访问127.0.0.1:8036来看负载均衡的状态监控了。
  4. 再说说拉勾网吧,难度很低,几乎没有反爬,甚至不限制IP访问频率!当然,你不能调用网络上盛传的那个端口来获取json,况且那个接口只能获取列表页,不能获取详情页。
  5. IP变化少的情况下要考虑网站的CDN,如果不用多地区的不同IP,爬虫速度很难上去,毕竟CDN节点会有限速啊!

熟悉了框架,就能用它来爬取高难度的网站了。目前计划爬取的几个目标:

  1. 京东。全站爬取估计很费劲,京东自称有500多万sku,京东虽然是树形结构,但是这么多商品肯定要细分类才能爬到更多数据,URL去重无法避免,不同组合之间的元素会有交集啊。因为是电商,还需要它的评论数据,很多热门商品都是几万几十万评论,爬起来也很费时。当然,之前我做过京东商品抢购的脚本,虽然没能抢到茅台,但是能用到这个爬虫中。
  2. 拼多多。电商中的黑马,虽然我从来不用。
  3. 唯品会,媳妇儿的最爱,怎能不光顾下?
  4. 携程,去哪儿,爱彼迎。爱旅游的我自然对他们感兴趣
  5. 出行必备滴滴。这个得看看它的APP,看看有没有接口,估计难度不小。
  6. 12306,爬虫们的最爱。
  7. 小红书,潮人们的必备APP
  8. 抖音,快手,虽然我从来不用,也没有装。刷视频比追剧还要浪费时间
  9. 学习强国,这个PC端我已经写好了,APP端因为目前要用HyperV(docker),不太方便使用安卓模拟器。还需要一个题库API,有时间我做下

不说了,这些够我忙活大半年了。边爬边分析吧。

拉勾网爬虫截屏,单机4进程*10线程, 6个splash instance,200KB/s – 1MB/s,平均2.5个职位/秒