有关爬虫框架的设计的一些备忘

我们公司一直在使用自己设计的爬虫框架，这么做的初衷是让框架保持简单，新手可以很快写一个爬虫工作。但是也遇到过许许多多的问题。这里记一下，如果要重新写一个爬虫框架的话，这些问题必须好好处理，可以少走很多弯路。

1.任务队列

爬虫肯定是要用到任务队列的。将每个页面的抓取分成任务，可以让任务之间互不影响，方便监控，也方便调度。任务队列是个很大的话题，我们用的是beanstalkd，它轻量，速度快，但是也有一些缺点。我对任务队列没有什么研究，这里就不比较各个方案了。但是爬虫需要的任务队列要求如下：

1. 必须能够快速切换。一个任务就是一个网络请求+解析结果。这样划分比较合理，可以看到对某个页面的抓取状态。这就要求任务队列的吞吐量很高，要频繁的放、取任务。我们每天的抓取任务在千万级别。
2. 支持分组（tube）。这样就可以对不同的爬虫任务循环执行。单队列可能造成对抓去网站DoS攻击，很不友好。
3. 支持优先级。
4. 支持重试，延迟重试。但不是必须，这个可以在爬虫队列实现。

2.数据的去重

如果没有考虑到数据去重，那么每一次执行爬虫任务都会带来新数据，这肯定是不合理的，所以爬虫每次运行都要考虑到用某种方式判定是否是一条已经存在的数据。

比较通用的方法是通过hash来判定重复。我们就是用的这种方案：对每一条数据挑一些字段（全文hash很危险，经常造成数据重复。比如有一个字段变化了，但其实应该作为一条数据处理）来计算hash值，存入数据库。在数据库中插入的时候根据hash值是否存在。

这种方案存在几个问题：

1. hash碰撞。如果手动实现处理hash碰撞的情况，又是一个复杂的过程。目前我们是没有考虑这个的，因为我们的每一个目标网站数据量不是很多，对每一个目标网站使用一个collection存放，就大胆地假设了数据不会存在hash碰撞的情况。但是这可能是一个隐患。可以看一下这个项目，很有意思，可以对两个完全不同的pdf修改让它们的sha1结果一模一样但是不改变显示内容。
2. 对数据库的压力。爬虫集群如果规模很大，那么意味着每一次爬虫任务都会去查询数据库，我们的Mongo集群经历过多次压力过大的问题。

其实我觉得，比较合理的方式是建立一种“爬虫任务–页面–数据”之间的关系。根据这种关系来去重，比如如果在抓取页面的时候就能判断过这个页面已经被处理过。那么就可以认为页面上的数据已经存在，可以节省很多操作。

这就需要下面下载与处理的分离。

3.下载与处理分离

这里想说的是，将下载和处理页面解耦。这样做的好处是你可以部署一个网络比较好或者有特殊要求的（比如国外ip，国内ip）集群来专门下载网页，然后用一些配置高的机器用来处理网页，这可能会节省一些vps租金。因为众所周知，爬虫比较耗费的资源是网络请求和ip。这样做的缺点是会增加框架的复杂程度。

此外，还有一个好处是上面提到的，下载好的页面可以做简单的判断，如果是已经处理过的页面并且没有发生更新，那么就直接结束这个任务。如果是个新的页面，就要交给后面的某个处理程序继续处理，像一个管道一样。

而且，还可以对下载步骤（或处理步骤）做一些Hook，如果我想保存下载所有的下载过的页面，就可以在下载完成的时候，将页面同时交给一个线程来上传到S3 bucket，同时交给一个线程做抽取任务。

这种解耦对监控来说也应该方便很多。

4.监控

需要监控的地方：

1. 任务队列中的状态
2. 每个任务的执行情况，比如异常等
3. 数据的增长
4. 追踪每个任务执行带来的数据

最好监控到每一次任务执行的参数，比如从任务队列中获得的任务信息，执行时间等。以及任务失败时候的异常，这样发现爬虫挂掉就很方便。另外需要特别注意的是，任务没有异常抛出，但实际上一次任务没有带来数据。就好比程序实际是错的，但是实际跑一次并不会挂掉。这种情况很难避免，即使你处理异常的时候非常小心，也有可能捕获了不想捕获的异常，唯有从监控上下功夫。最好是将任务执行和数据存储关联起来。在存数据的时候，记录这条数据是哪一个任务带来的。如果一次任务没有带来数据，也应该有警告。当然如果目标就是抓取一个列表页面，提取url，没有数据是正常的，这种情况应该可以被过滤掉。总之重点是，一个任务应该和进来的数据有关联，可以查看一个任务带来多少数据，亦可以查看某条数据是由哪个任务带来的。

第1条和第3条可以使用Grafana等组合Metric来实现。

目前来看，ElasticSearch用来做日志分析挺不错的。其他没有使用过。

暂时就想到这个，最近经常会有一个动手写个框架的冲动。以上只是个人的经验和想法，并不一定是合适的方案，欢迎讨论。