写采集器（爬虫）遇到的那些坑

背景

虽然写过很多爬虫，近期却瞒着写一个采集器。一整套爬虫的集合，踩坑不少，特别写一文记录下来。

语言的选择

Python！

应为语言足够灵活，而且又足够多的库选择。项目之初我还考虑过使用erlang。erlang的多进程特性虽然很好，但是erlang在编码处理，文本解析方面的能力太弱，写代码写的十分痛苦。故弃之。据说golang可能会更好，但是我还没对这语言深入研究，用到公司的项目上来，实在有些欠妥。

Request包

很多人用python写爬虫，可能会使用Scrapy这样的框架，但是我觉得因为抓取这种事情，很多时候，往往是两个程序员之间的对决。所以，我倾向于更灵活的使用一个Request包，然后自己各方面分析来构建请求包，达到抓取数据的目的。

selenium

不是所有的页面都能通过构造请求包来获取的，尤其是很多需要验证的页面。还有很多页面的数据，需要通过一大串js运算才会显示出来，这样无疑增加了抓取的难度，但是兵来将挡，水来土掩。

这个时候借助测试人员常用的自动化测试工具selenium，模拟人的访问，获取到你想要的数据。当然selenium也是对python兼容的。

当然，模拟自动化测试的方式，难度大，性能差，不到万不得已不出招。

项目结构

项目结构图

• collector:
  程序的主体

  • repo: 公共模块，将抓取和分析的代码抽取出来，还要又对时间的运算类，和日志类，以及操作数据库和消息队列的类。

  • task: 任务模块，任务要做的事即使确定什么时候执行抓取，抓取的结果放到那里。

  • worker：工作者模块，抓取数据和分析数据的模块。

• tests：同等的目下， 是测试用例

• runtime： 目录下是日志和错误数据的记录。

• run*.py： 这些每个抓取的入口。因为是多进程的方式，故而分成多个入口。不同入口，对应不同的抓取内容。

多进程

为什么使用多进程的形式呢？因为线程不好控制，我的每个抓取进程之下，不同的任务用到不同的线程。但是不同抓取内容，没有耦合的东西，所以采取这样进程的方式，好管理，想启动就启动，想关掉，kill掉进程就是了。

使用nohup命令在后台执行程序：

nohup python run_xxx.py > runtime/xxxx.out &

异常的处理

采集器程序，是要把外部资源转化为内部资源。凡是依赖外部的情况，都要考虑异常的风险。比如我抓取的很多东西在境外，因为某些不可描述的原因，网络服务一直很不稳定。所以超时处理的是必须的，超时抛出异常，而这个异常是我们认为没什么大不了的事情，所以没有必要因为这个异常破坏程序的执行，所以我们只要抓取到异常，就直接重新发起请求再来一次就是了。

当然，这样的处理过于简单除暴了，最好还是让程序让程序稍后发起请求，因为发生异常之后，我的程序会触发一个事件，这个事件回去检查最近数据的一致性。做到尽量让程序来监督程序。

总结

简单总结一下，还有什么坑，我想到再补。