3.1 为链接爬虫添加缓存支持

3.2 磁盘缓存

3.2.1 实现

3.2.2缓存测试

3.2.3节省磁盘空间

3.2.4 清理过期数据

3.2.5缺点

3.3 数据库缓存

3.3.1 NoSQL 是什么

3.3.2 安装 MangoDB

3.3.3 MongoDB 概述

3.3.4 MongoDB 缓存实现

3.3.5 压缩

3.3.6 缓存测试

3.4 本章小结

3.1 为链接爬虫添加缓存支持

要想支持缓存，我们需要修改第1章中编写的download函数，使其在要想支持缓存，我们需要修改第1章中编写的download函数，使其在URL下载之前进行缓存检查。另外，我们还需要把限速功能移至函数内部，只有在真正发生下载时才会触发限速，而在加载缓存时不会触发。为了避免每次下载都要传入多个参数，我们借此机会将download函数重构为一个类，这样参数只需在构造方法中设置一次，就能在后续下载时多次复用。下面是支持了缓存功能的代码实现。

class Downloade r :

de f 一＿init_ ( s elf, delay= S ,

user_agent＝ ’ wswp ’ ， proxies=None,

num retries=! , cache=N。ne ) :

s elf. throttle = Throttle ( delay)

self . us er_agent = user_agent

s e l f . proxies = proxies

s e l f . num retries = num retries

s e l f . cache = cache

de f_call_( s elf, url ) :

result = None

if self.cache :

try :

result = se lf. cache [ url ]

except KeyError :

# url is not ava i l able in cache

pass

else:

if self. num retries > 0 and \

500 <= result ［ ’ code ’ l < 600 :

# s erver e rror so ignore result from cache

# and re-down load

result = N.ne

if result is N.ne :

# result was not loaded from cache

# so still need to download

self . throttle . wait ( ur l )

proxy = random . choice ( s elf . proxi e s) if s e lf. proxies

else None

headers ＝｛ ’ User-agent ’ ： s el f . user_agent }

result = s el f . download ( url , headers , pr。xy,

self . num retries )

if self . cache :

# s ave result to cache

self . cache [ url ] = result

return result ［ ’ html ’ ］

def downl oad (self, url , headers , proxy , num_retr ies ,

data=None ) :

return ｛ ’ html ’ ： html ，

前面代码中的Download类有一个比较有意思的部分，那就是 _call_ 特殊方法，在该方法中我们实现了下载前检查缓存的功能。该方法首先会检查缓存是否已经定义。如果已经定义，则检查之前是否已经缓存了该URL。如果该URL己被缓存，则检查之前的下载中是否遇到了服务端错误。最后，如果也没有发生过服务端错误，则表明该缓存结果可用。如果上述检查中的任何一项失败，都需要正常下载该 URL，然后将得到的结果添加到缓存中。这里的 download方法和之前的download函数基本一样 ,只是在返回下载的HTML时额外返回了 HTTP态码，以便在缓存中存储错误码。当然 ,如果你只需要一个简单的下载功能，而不需要限速或缓存的话，可以直接调用该方法，这样就不会通过 _call_ 方法调用了。

3.2 磁盘缓存

要想缓存下载结果，我们先来尝试最容易想到的方案，将下载到的网页存储到文件系统中。为了实现该功能，我们需要将URL安全地映射为跨平台的文件名。表 3.1所示为几大主流文件系统的限制。

为了保证在不同文件系统中，我们的文件路径都是安全的，就需要限制其只能包含数字、字母和基本符号，并将其他字符替换为下划线，其实现代码

>>＞import re

>>> url ＝ ’ http:/ /example . web s craping . c。m/de fault /view/

Australia- 1’

>>＞ re . sub （ ’ ［《／0-9a-zA- Z＼-］’ ，'_' ， url )

'http_//example . webs c raping . com/default /view/Australia- 1 ’

3.2.1 实现

介绍一下了创建基于磁盘的缓存时需要考虑的文件系统限制，包括允许使用哪些字符、文件名长度限制，以及确保文件和目录的创建位置不同。把URL到文件名的这些映射逻辑结合起来，就形成了磁盘缓存的主要部分。

在上面的代码中，构造方法传入了一个用于设定缓存位置的参数，然后在urltopath方法中应用了前面讨论的文件名限制。现在，我们还缺少根据文件名存取数据的方法，下面的代码实现了这两个缺失的方法。

在一setitern （）一中，我们使用 u r l _to _pa th （）方法将 URL 映射为安全文件名，在必要情况下还需要创建父目录。这里使用的pickle模块会把输入转化为字符串，然后保存到磁盘中。而在＿getitem_ （）方法中，首先将URL映射为安全文件名。然后，如果文件存在，则加载其内容，并执行反序列化，恢复其原始数据类型：如果文件不存在，则说明缓存中还没有该URL的数据，此时会抛出KeyError异常。

3.2.2缓存测试

现在，我们通过向爬虫传递cache回调，来检验DiskCache类。该类的完整源代码可以从https : / /bitbucket .org/wswp/code/src/tip/chapter03/diskcache.py获取。我们可以通过执行如下脚本，使用链接爬虫测试磁盘缓存。

第一次执行该命令时，由于缓存为空，因此网页会被正常下载。但当我们第二次执行该脚本时，网页加载自缓存中，爬虫应该更快完成执行，其执行结果如下所示。

和上面的预期一样，爬取操作很快就完成了。当缓存为空时，我的计算机中的爬虫下载耗时超过23 分钟1 而在第二次全部使用缓存时，该耗时只有0.186秒（比第一次爬取快了超过7000倍。由于硬件的差异，在不同的计算机中的准确执行时间也会有所区别。不过毋庸置疑的是，磁盘缓存速度更快。

3.2.3节省磁盘空间

为最小化缓存所需的磁盘空间，我们可以对下载得到的HTML文件进行压缩处理。处理的实现方法很简单，只需在保存到磁盘之前使用zlib压缩序列化字符串即可，如下面的代码所示。

而从磁盘加载后解压的代码如下所示。

returnpickle.loads(zlib.decompress(fp.read()))

压缩完所有网页之后，缓存大小从 4.4MB下降到2.3MB，而在我的计算机上爬取缓存示例网站的时间是0.212秒，和未压缩时的0.186秒相比只是略有增加。当然，如果你的项目对速度十分敏感的话，也可以禁用压缩功能。

3.2.4 清理过期数据

当前版本的磁盘缓存使用键值对的形式在磁盘上保存缓存，未来无论何时请求都会返回结果。对于缓存网页而言该功能可能不太理想，因为网页内容随时都有可能发生变化，存储在缓存中的数据存在过期风险。本节中，我们将为缓存数据添加过期时间，以便爬虫知道何时需要重新下载网页。在缓存网页时支持存储时间戳的功能也很简单，如下面的代码所示。

在构造方法中，我们使用timedelta对象将默认过期时间设置为30天。然后，在＿set一方法中，把当前时间戳保存到序列化数据中：而在＿get一方法中，对比当前时间和缓存时间，检查是否过期为了测试过期时间功能，我们可以将其缩短为5秒，如下所示。

和预期一样，缓存结果最初是可用的经过5秒的睡眠之后，再次调用同-URL，则会抛出KeyError异常，也就是说缓存下载失效了

3.2.5缺点

基于磁盘的缓存系统比较容易实现，无须安装其他模块，并且在文件管理器中就能查看结果。但是，该方法存在一个缺点即受制于本地文件系统的限制。本章早些时候，为了将URL映射为安全文件名，我们应用了多种限制，然而这又会引发另一个问题，那就是一些URL会被映射为相同的文件名。比如，在对如下几个URL进行字符替换之后就会得到相同的文件名。

这就意味着，如果其中一个URL生成了缓存，其他3个URL也会被认为已经生成缓存，因为它们映射到了同一个文件名。另外，如果一些长URL只在255个字符之后存在区别，截断后的版本也会被映射为相同的文件名。这个问题非常重要，因为U虹的最大长度并没有明确限制尽管在实践中U肚很少会超过2000个字符，且早期版本的IE浏览器也不支持超过2083个字符的U虹。避免这些限制的一种解决方案是使用URL的哈希值作为文件名尽管该方法可以带来一定改善，但是最终还是会面临许多文件系统具有的一个关键问题，那就是每个卷和每个目录下的文件数量是有限制的。如果缓存存储在FAT32 文件系统中，每个目录的最大文件数是65535。该限制可以通过将缓存分割到不同目录来避免，但是文件系统可存储的文件总数也是有限制的。我使用的ext4分区目前支持略多于1500万个文件，而一个大型网站往往拥有超过1亿个网页。很遗憾，DiskCache方法想要通用的话存在太多限制。要想避免这些问题，我们需要把多个缓存网页合并到一个文件中，并使用类似B＋树的算法进行索引。我们并不会自己实现这种算法，而是在下一节中介绍己实现这类算法的数据库。

3.3 数据库缓存

为了避免磁盘缓存方案的己知限制，下面我们会在现有数据库系统之上创建缓存。爬取时，我们可能需要缓存大量数据，但又无须任何复杂的连接操作，因此我们将选用NoSQL数据库，这种数据库比传统的关系型数据库更易于扩展。在本节中，我们将会选用目前非常流行的MongoDB作为缓存数据库。

3.3.1 NoSQL 是什么

NoSQL全称为Not OnlySQL，是一种相对较新的数据库设计方式。传统的关系模型使用的是固定模式，并将数据分割到各个表中。然而，对于大数据集的情况，数据量太大使其难以存放在单一服务器中，此时就需要扩展到多台服务器不过，关系模型对于这种扩展的支持并不够好，因为在查询多个表时，数据可能在不同的服务器中。相反，NoSQL数据库通常是无模式的，从设计之初就考虑了跨服务器无缝分片的问题。在NoSQL中，有多种方式可以实现该目标，分别是列数据存储（如 HBase ）、键值对存储（如 Redis ）、面向文档的数据库（如MongoDB）以及图形数库（如 Neo4j ）。