搭建易配置的分布式爬虫架构

过年之后写的第一篇。
最近需要研究一下爬虫，这次的爬虫不是简单的requests+selenium+bs4或者是scrapy就能搞定的。因为要解决爬取多站点（200+）的问题，考虑到工作量的问题，所以要搭建一个可以较为容易配置的分布式爬虫。

---

一、工具选择

语言：python
考察过用java的爬虫库，虽然流程原理基本相同，但是相关库，python好太多。
库：scrapy-redis
之前写的爬虫无非就是requests+selenium+bs4的组合，IP池用的第三方提供的http隧道代理，验证码上传到打码云解码返回值。之前的Facebook用了一把scrapy，但是总感觉scrapy这个框架太重，之前那种数量级的爬虫根本用不上。
这次的任务很复杂，主要难点在于爬多个站点，到时候的任务分发管理和配置难易程度是首要考虑的东西。看过pyspyder，这个库倒是很好配置，但是任务分发的支持就比较弱。所以最终选择是scrapy-redis库，就是在scrapy的基础上，很方便的实现了利用redis做任务分发。如果中间键控制好，配置多种情况，对于不同站点，就是堆工作量了。

二、流程控制

这次宜配置的框架应该做好几个点，这套框架应该就可以很流畅的运转起来了。

1. 下载器中间件

下载器中间件可以作为一个通用性组件

登录

登录如果是账号密码是较为好处理的，再麻烦一点是二维码登录，这个可以把二维码保存下来扫描就行，更麻烦一点是邮箱验证，这个就需要监测邮箱的收件，目前见过最复杂的是图片点击和移动验证，基本无解（移动验证据说有有已经破解了）。

IP池

IP代理可以考虑两种，钱多自己在云服务器上买几十个上百个实例，自己搭建一个IP池，优点是稳定，我刚才看了一下AWS如果启100个实例需要多少钱，不得不感慨，云服务商真的是太赚钱太赚钱了。如果没有钱，有专门做这个生意的IP供应商。但是，花出去的钱一定和IP的稳定性成正比。

JS模拟动作

比如说滑动个窗口什么的

cookies切换

大部分网站都是一个cookies走到底，但是有些网站cookies是变化的，这个需要随时监测。

UA池

可能是以上几点中难度最小的了。

2.爬虫中间件

如果爬虫放在服务器上，selenium用武之地不大，主要考虑抓包解析json。如果是动态页面，就需要上scrapy-splash，利用splash渲染页面再返回结果。
需要说明的是，动态页面可以归为一类，静态页面归为一类，这部分可配置的部分只有这个，所以主要工作量在于爬虫中间件。在搭建框架过程中需要好好设计。

3.数据解析与保存

scrapy的Item通过itempipeline直接存进数据库。这里有一个问题，需要记录最近一次爬虫爬取数据的日期，这样后期可以减少轮询。对于数据库的选择首选mongodb。这个组件也是公用的。

4.任务调度

主角redis登场。先说为什么会用它。
但是如果在面对一些比较大型的站点的时候，单个scrapy就显得力不从心了。要是我们能够多个Scrapy一起采集该多好啊 人多力量大。
很遗憾Scrapy官方并不支持多个同时采集一个站点，虽然官方给出一个方法：
将一个站点的分割成几部分，交给不同的scrapy去采集。
实在是蠢的一逼。因为不同scrapy进程之间数据不会共享，一个网页并不知道哪些爬了哪些没爬。解决方案是将几个scrapy的任务调度放在一个redis中，利用redis进行去重。（其实就是这么简单，我也不知道scrapy为什么不支持。）
总结一下：

1. Scrapy-Reids 就是将Scrapy原本在内存中处理的 调度(就是一个队列Queue)、去重、这两个操作通过Redis来实现
2. 多个Scrapy在采集同一个站点时会使用相同的redis key（可以理解为队列）添加Request 获取Request 去重Request，这样所有的spider不会进行重复采集。效率自然就嗖嗖的上去了。
3. Redis是原子性的，好处不言而喻(一个Request要么被处理 要么没被处理，不存在第三可能)

另外，scrapy-redis还有集群版。这个后期需要好好研究一下。

---

爬虫框架部分就到这里，其实里面的坑还是不少，需要潜心去研究。能做好爬虫（大型）也是不用愁工作的，以后更新一下爬虫实践部分。