爬虫进阶的那些事儿

1、困难

​ 下载—>解析—>储存，一般是理想状态，爬虫面对的不确定因素是目标网站的稳定性，传统web开发不稳定因素主要是客户。当两者结合，要面对的不稳定因素将大大增加。

​ 之前开发的项目就是两者的结合，业务流程是这样的，客户授权登录—>爬虫登录—>目标网站。难点再哪，目标网站需要登录验证，二次短信验证，所以都是实时交互爬取的。所以要考虑用户密码、账号、验证码、误点等一系列问题，还要面对N个目标网站的不稳定。

2、应对措施

​ 主要问题有两个：一个数据的完整性，另一个是超时。

• 数据的完整性

  数据的不完整主要是目标网站的稳定性不好，因为即使是正常人去登录查看数据，数据也不能保证每次都完整正确的。

  应对措施：

  • 重试

  ​ 重试包括两方面，爬虫内部的重试，访问失败、获取资源失败等。第二种就是让用户重新授权登录。

  • 缓存

  ​ 重试可以一定程度提供成功率，但还是不能保证数据的完整性，所以有加了redis缓存，将前一次的获取的数据保存，与第二次的数据进行。将数据的完整性大大提供。

• 超时

  安全起见，一般情况，会给爬虫定一个固定时间，超时报错。

  • 爬虫的访问时间过长

  ​ 之前的爬虫是整个流程一路走下来，相当于黑盒，也不知道，爬到什么程度，失败了还是数据量太多。后来将爬虫更加细致的拆分开来，每个步骤单独起个服务，实时记录日志。

  • 数据太多

    数据太多，会导致解析时间变长，selenium的解析方式就相当的慢，换成lxml就好很多。

• 目标网站升级问题

  ​ 需要爬取的目标网站有N个，不知道哪个网站会改版、哪个会升级。所以用Scrapy做了个预警项目，定时爬取目标网站的公告列表，如果有升级信息，及时推送给相关人员重点关注。

3、进阶

3.1、爬虫微服务化

​ 大多数的爬虫框架都是将下载、解析、存储之类的拆分出来，实际遇到的问题可能是比较复杂的流程，不妨把下载再拆分一下，如上面的将登录、验证、二次验证、采集等拆分成独立的模块。将爬取步骤拆分，主要解决的就是模块通信问题，说白了就是将cookie、User-Agent、headers、IP等信息保存，传递给下一步。

​ 将流程解耦，可以更加透明查看进行的步骤，更好的控制，如果某个模块失败，可以更换另一台服务，如果需要重新执行上一步的验证步骤，可以重新执行上一步的服务。

3.2、selenium

​ 一般都是最后的选择，开发较快，用好不容易，解决启动的较慢的方式就是创建selenium池。

思路：

• 初始化10个selenium，用完之后清除cookie。
• 设置阻塞队列，不宜过多，因为实时交互的。
• 设置最多开启selenium的数量，根据服务器的性能决定个数。
• 设置非核心selenium的空闲超时时间。
• 设置服务请求不过来时候的拒绝策略。