Scrapy08：scrapy-deltafetch，让爬虫有了记忆

deltafetch，让爬虫有记忆

前言

”我化作人鱼，只有七秒钟的记忆“。

很多时候，爬虫程序跑着跑着，因为网络故障或者程序异常就宕掉了。无奈之下只能重启重新爬取。为了避免这种每次重头再来的情况，我们都会利用mysql、redis、文本等方式，来记录一下爬取过的url。

这也提高了程序整体的复杂度。而scrapy提供了一个模块来解决了这个痛点，仅仅两行配置就解决了这个问题。

断点续爬

在Scrapy系列的第一篇，我就写了一个爬虫常见断点续爬问题。

假如有1000个页面需要爬取，爬到第999个页面，进度条马上满格的时候，程序咯噔一下挂了，就差一个，但是还是没爬完啊，咋整？我选择重新启动程序，那么你说我怎么样才能直接从第999个开始爬取呢？

这里先讲讲我写的第一个爬虫：爬取10+个地市的poi信息。

17年实习，第一次开发爬虫，也不知道有高德poi接口啥的，于是就找了个网站来爬取poi信息。当时那个网站估计还在起步阶段，服务器带宽应该不高，访问速度是真的慢，而且动不动维护停站，所以我的程序也得跟着停止。如果每次启动都重新爬取，估计几年也爬不完，于是我想了个办法。

我先将所有地市下所有区县数据的条数（网站上有）先手动录入到数据库表中，每次重新启动爬虫程序的时候，先统计结果数据表中各个区县已经爬取的条数，与总条数进行对比。如果小于的话，说明还没有爬取完，然后通过某区县已爬取条数 / 网站每页展示条数计算出我已经爬取到此区县的页数，再通过余数定位到我爬到了此页面的第几个。通过这种方法，最后无丢失爬取了163w条数据。

换种思路，将爬取的url放到表中，重启程序开始爬取url的时候，先去判断url是否存在于数据表中，如果存在就不进行爬取，这样也能实现断点续爬。也是沿用了原始的url的去重的思路。

而今天，要讲的scrapy-deltafetch，完全不用考虑上面的这些问题！

Scrapy-deltafetch

上面的两种思路有两个共同点：

1. 手动实现断点逻辑代码
2. 依赖外部存储/数据库

这样就加大了开发的工作量。所以我们这里就引入了scrapy-deltafecth模块，两行配置就可以完美解决上面的两个问题。

原理

deltch在Scrapy中是作为一个Spider中间件存在的。原理就是内置一个内嵌式KV数据库BerkeleyDB，在执行yield item的时候，将response.request加密作为key存储到内嵌式数据库中。

这样，每次爬取的时候，都会去内嵌数据库中判断这个url是否已存在，存在就不再爬取。

这时候就有人要说了，这不还是用到了数据库吗？

内嵌式数据库和数据库是有区别的：

1. 内嵌式数据库嵌入到了应用程序进程，同应用程序在相同的地址空间中运行，所以数据库操作不需要进程间的通讯
2. 嵌入数据库是一种具备了基本数据库特性的数据文件，提供了一套API去访问、管理一个数据库文件，采用程序方式直接驱动，而非引擎响应方式驱动

<