直播项目阶段性总结-爬虫

爬虫总结

项目展示的数据都是由爬虫爬取的,在使用过程中出现了很多没有注意和意料之外的一些问题,特此总结一下提醒自己。

历程

爬虫开发的技术路线经过了好几个阶段,将一一总结:

  • 原生写法urllib
  • Requests + Gevent + Celery
  • Scrapy + Redis

原生写法urllib

这个阶段是刚开始学习爬虫,对如何构造和理解爬虫以及相关库的用法都不熟悉,是学习踩坑阶段。主要学习了响应的解析和处理,XPath和正则提取数据。还探索性使用自动化测试组件Selenium,调用浏览器直接爬取数据,用以对付一些反爬虫策略复杂的网站。在对爬虫有了基础的了解以后,开始准备在生产环境使用。爬虫根据站点变化经常需要调整,也需要定时任务定期执行,为了适应这种情况进行一次技术升级。

主要缺点:结构不清晰,写法繁琐。修改爬虫的时候不方便,模块化程度不高。

Requests + Gevent + Celery

此阶段完成开发主要为:

  1. 模块化。
  2. 爬虫定时启动管理。
  3. 提高爬取效率,初步反爬虫策略。

针对每点都做了以下工作:

  1. 重新设计,开发了爬虫基类,包含启动和队列函数。子类继承后,只需要补全格式化数据和存储部分即可。采用requests替代python标准库,提升开发效率。
  2. 采用Celery作为爬虫任务管理,定时启动爬虫、超时删除等,并开发Flask-Celery(py3版本)插件。
  3. 从试验结果看来,爬虫运行时间主要浪费在I/O读写(网络通信)上,还占用&浪费CPU工作时间。故引入了协程Gevent,在I/O读写时CPU可以继续其他数据的分析和存储任务,总体上缩短爬虫运行时间。采用的初步的反爬虫措施,设置user-agent,随机间隔几秒启动对站点的访问请求。

配合WEB展示部分,直播爬虫站点在这个时期上线了,达到了自行更新直播房间的情况。但仍然存在以下的问题:

  • 模块化仍然有优化的需要,仅能先频道后房间的方式爬取。
  • 爬虫一旦超时或发生错误,Celery只能重新启动爬虫任务,无法在某个特定频道/房间请求上重试。
  • 由于生产环境机器性能不足(AWS免费套餐),导致爬虫进程在运行占用CPU的时候,展示WEB站点的请求几乎得不到正确的响应。

这些问题都影响到项目正常运行,所以还是进行技术升级修正。恰逢此时,爬虫包scrapy终于完成了对py3的兼容,研究后认为它的框架设计基本上能解决我遇到的问题,而且更灵活,配置和修改爬虫都非常方便。故采用Scrapy进行升级替换。

Scrapy + Redis

Scrapy的基本模块和运行方式可以参照下图:

按运行顺序说明:

  1. Spider(请求构造工厂):开发人员自定义的爬虫请求Request、数据分析以及构造Item。构造后的爬虫请求Request进入Scheduler,Item进入Pipeline。
  2. Scheduler(调度程序):接收到构造好的爬虫请求后安排队列,按队列先进先出方式提供请求给Downloader。默认队列为multiprocess.queue,此处我采用了redis替换,这样当进程意外终止甚至机器重启的情况下仍可以恢复爬虫继续。
  3. Downloader(下载器):接收到请求Request后访问站点,将得到的响应返还给Spider。此处引入了user-agent替换插件,可根据已存在user-agent文本随机替换请求相应值。
  4. Pipeline(管道):在Spider初步处理得到Item,Item会被发送到Pipeline进一步处理,并且多个Spider可以生成相同格式的Item交给Pipeline统一处理。Item流动经过的Pipeline顺序通过weight(权重)设置。
  5. 以上均由Engine操作执行。

Scrapy采用Twisted实行多爬虫异步爬取,Twisted的异步进程处理非常强大,在等待I/O过程中会释放占用的CPU,这样多个爬虫即使在单CPU的情况下仍然能高效的切换进行。

可以说Scrapy解决了我所有的项目痛点,在生产环境中的表现也很好,目前运行稳定。

不采用PySpider理由

PySpider研究后就我理解来说,它更像是一揽子完备的解决方案,自由度低。Scrapy相对只是个第三方库,使用的方式更自由,且插件丰富,自己定制开发也方便,更适合个人项目。

阶段总结

目前Scrapy已经很好胜任了我的爬虫任务需要,接下来的爬虫功能追加将会在弹幕读取上下功夫。如果Scrapy无法满足需要,优先开发Scrapy自定义插件,实在不行才考虑替换Scrapy。

你可能感兴趣的:(Python,爬虫)