分布式爬虫原理

当爬取内容过多，需要多机合作的时候，就需要用到分布式系统

Scrapy爬虫虽然是异步加多线程的，但是我们只能在一台主机上运行，所以爬取效率还是有限的，分布式爬虫则是将多台主机组合起来，共同完成一个爬取任务，这将大大提高爬取的效率。

Scrapy单机爬虫中有一个本地爬取队列Queue，这个队列是利用deque模块实现的。如果新的Request生成就会放到队列里面，随后Request被Scheduler调度。之后，Request交给Downloader执行爬取，简单的调度架构如下图所示。

image.png

我们需要做的就是在多台主机上同时运行爬虫任务协同爬取，而协同爬取的前提就是共享爬取队列。这样各台主机就不需要各自维护爬取队列，而是从共享爬取队列存取Request。但是各台主机还是有各自的Scheduler和Downloader，所以调度和下载功能分别完成。如果不考虑队列存取性能消耗，爬取效率还是会成倍提高。

如果两个Scheduler同时从队列里面取Request，每个Scheduler都有其对应的Downloader，那么在带宽足够、正常爬取且不考虑队列存取压力的情况下，爬取效率会有什么变化？没错，爬取效率会翻倍。

这样，Scheduler可以扩展多个，Downloader也可以扩展多个。而爬取队列Queue必须始终为一个，也就是所谓的共享爬取队列。这样才能保证Scheduer从队列里调度某个Request之后，其他Scheduler不会重复调度此Request，就可以做到多个Schduler同步爬取。这就是分布式爬虫的基本雏形，简单调度架构如下图所示。

image.png

我们需要做的就是在多台主机上同时运行爬虫任务协同爬取，而协同爬取的前提就是共享爬取队列。这样各台主机就不需要各自维护爬取队列，而是从共享爬取队列存取Request。但是各台主机还是有各自的Scheduler和Downloader，所以调度和下载功能分别完成。如果不考虑队列存取性能消耗，爬取效率还是会成倍提高。

1. 维护爬取队列

那么这个队列用什么来维护？首先需要考虑的就是性能问题。我们自然想到的是基于内存存储的Redis，它支持多种数据结构，例如列表（List）、集合（Set）、有序集合（Sorted Set）等，存取的操作也非常简单。

Redis支持的这几种数据结构存储各有优点。

• 列表有lpush()、lpop()、rpush()、rpop()方法，我们可以用它来实现先进先出式爬取队列，也可以实现先进后出栈式爬取队列。

• 集合的元素是无序的且不重复的，这样我们可以非常方便地实现随机排序且不重复的爬取队列。

• 有序集合带有分数表示，而Scrapy的Request也有优先级的控制，我们可以用它来实现带优先级调度的队列。

我们需要根据具体爬虫的需求来灵活选择不同的队列。

2. 如何去重

Scrapy有自动去重，它的去重使用了Python中的集合。这个集合记录了Scrapy中每个Request的指纹，这个指纹实际上就是Request的散列值。

主要是这三个方法:

• request_seen:判断requests对象是否已经存在,如果没有就添加到“dmoz:dupefilter”；
• request_fingerprint:调用函数request_fingerprint；
• request_fingerprint：主要是对请求进行加密生成指纹；

import hashlib


def request_fingerprint(request, include_headers=None):
   if include_headers:
       include_headers = tuple(to_bytes(h.lower())
                                for h in sorted(include_headers))
   cache = _fingerprint_cache.setdefault(request, {})
   if include_headers not in cache:
       fp = hashlib.sha1()
       fp.update(to_bytes(request.method))
       fp.update(to_bytes(canonicalize_url(request.url)))
       fp.update(request.body or b'')
       if include_headers:
           for hdr in include_headers:
               if hdr in request.headers:
                   fp.update(hdr)
                   for v in request.headers.getlist(hdr):
                       fp.update(v)
       cache[include_headers] = fp.hexdigest()
   return cache[include_headers]

request_fingerprint()就是计算Request指纹的方法，其方法内部使用的是hashlib的sha1()方法。计算的字段包括Request的Method、URL、Body、Headers这几部分内容，这里只要有一点不同，那么计算的结果就不同。计算得到的结果是加密后的字符串，也就是指纹。每个Request都有独有的指纹，指纹就是一个字符串，判定字符串是否重复比判定Request对象是否重复容易得多，所以指纹可以作为判定Request是否重复的依据。

那么我们如何判定重复呢？Scrapy是这样实现的，如下所示：

def __init__(self):
   self.fingerprints = set()

def request_seen(self, request):
   fp = self.request_fingerprint(request)
   if fp in self.fingerprints:
       return True
   self.fingerprints.add(fp)

去重的方法，通过生成指纹识别：指纹默认由请求方法，url和请求体组成

• 使用sha1加密request得到指纹
• 把指纹存在redis的集合中
• 下一次新来一个request，同样的方式生成指纹，判断指纹是否存在reids的集合中，不存在插入</pre>

在去重的类RFPDupeFilter中，有一个request_seen()方法，这个方法有一个参数request，它的作用就是检测该Request对象是否重复。这个方法调用request_fingerprint()获取该Request的指纹，检测这个指纹是否存在于fingerprints变量中，而fingerprints是一个集合，集合的元素都是不重复的。如果指纹存在，那么就返回True，说明该Request是重复的，否则这个指纹加入到集合中。如果下次还有相同的Request传递过来，指纹也是相同的，那么这时指纹就已经存在于集合中，Request对象就会直接判定为重复。这样去重的目的就实现了。

Scrapy的去重过程就是，利用集合元素的不重复特性来实现Request的去重。

对于分布式爬虫来说，我们肯定不能再用每个爬虫各自的集合来去重了。因为这样还是每个主机单独维护自己的集合，不能做到共享。多台主机如果生成了相同的Request，只能各自去重，各个主机之间就无法做到去重了。

那么要实现去重，这个指纹集合也需要是共享的，Redis正好有集合的存储数据结构，我们可以利用Redis的集合作为指纹集合，那么这样去重集合也是利用Redis共享的。每台主机新生成Request之后，把该Request的指纹与集合比对，如果指纹已经存在，说明该Request是重复的，否则将Request的指纹加入到这个集合中即可。利用同样的原理不同的存储结构我们也实现了分布式Reqeust的去重。

3. 防止中断

在Scrapy中，爬虫运行时的Request队列放在内存中。爬虫运行中断后，这个队列的空间就被释放，此队列就被销毁了。所以一旦爬虫运行中断，爬虫再次运行就相当于全新的爬取过程。

要做到中断后继续爬取，我们可以将队列中的Request保存起来，下次爬取直接读取保存数据即可获取上次爬取的队列。我们在Scrapy中指定一个爬取队列的存储路径即可，这个路径使用JOB_DIR变量来标识，我们可以用如下命令来实现：

scrapy crawl spider -s JOB_DIR=crawls/spider

更加详细的使用方法可以参见官方文档，链接为：https://doc.scrapy.org/en/latest/topics/jobs.html。

在Scrapy中，我们实际是把爬取队列保存到本地，第二次爬取直接读取并恢复队列即可。那么在分布式架构中我们还用担心这个问题吗？不需要。因为爬取队列本身就是用数据库保存的，如果爬虫中断了，数据库中的Request依然是存在的，下次启动就会接着上次中断的地方继续爬取。所以，当Redis的队列为空时，爬虫会重新爬取；当Redis的队列不为空时，爬虫便会接着上次中断之处继续爬取。

4.架构实现

我们接下来就需要在程序中实现这个架构了。首先实现一个共享的爬取队列，还要实现去重的功能。另外，重写一个Scheduer的实现，使之可以从共享的爬取队列存取Request。幸运的是，已经有人实现了这些逻辑和架构，并发布成叫Scrapy-Redis的Python包。接下来，我们看看Scrapy-Redis的源码实现，以及它的详细工作原理。

实现方式：

        1.基于该组件的RedisSpider类

        2.基于该组件的RedisCrawlSpider类

分布式的优点

• 充分利用多机器的宽带加速爬取
• 充分利用多机的IP加速爬取速度

分布式需要解决的问题

• requests队列集中管理
• 去重集中管理

所以要用redis来解决。

有如下特征：

• 分布式爬取。可以启动多个spider工程，相互之间共享单个redis的requests队列。最适合广泛的多个域名网站的内容爬取。
• 分布式数据处理。爬取到的scrapy的item数据可以推入到redis队列中，这意味着你可以根据需求启动尽可能多的处理程序来共享item的队列，进行item数据持久化处理
• Scrapy即插即用组件。Scheduler调度器 + Duplication复制 过滤器，Item Pipeline，基本spider

分布式架构应该具有的特性：

• 分布式。这是最基本也是最核心的特性，分布式将允许我们通过横向扩展主机资源来提高爬取效率。

• 易扩展、易部署。当我们想要增加要爬取的网站时，只需要专注于爬取规则、解析规则、入库规则部分的代码编写就ok，其他的如日志、异常处理则让底层架构实现。

• 各功能高度模块化。模块化有利于架构的松耦合，以至于以后想要添加新的功能无需进行大的改动；同时也使得整个架构更清晰简明。

• 可监控。通过架构部署启动爬虫之后，可以通过某种方式监控Request队列实时大小、已入库的Item条数，以确认爬虫工作状态。

• 高性能。即使在单机上部署此架构也能充分利用主机CPU、带宽等资源，比较耗时的主要是下载页面和入库两个环节，当Request队列不断增长的时候，消费Request的能力也必须跟上，否则队列会消耗过多内存资源，且爬取效率低。入库同理，这两个环节都是IO密集型任务，所以恰好可以利用python的多线程来提高效率。

• Request队列、去重集合的持久化，实现断点续爬和增量爬取。

scrapy-redis架构 / scrapy-redis组件 ：

1、Scheduler（调度）：Scrapy改造了python本来的collection.deque(双向队列)形成了自己Scrapy queue，而scrapy-redis 的解决是把这个Scrapy queue换成redis数据库，从同一个redis-server存放要爬取的request，便能让多个spider去同一个数据库里读取。Scheduler负责对新的request进行入列操作（加入Scrapy queue），取出下一个要爬取的request（从Scrapy queue中取出）等操作。

2、Duplication Filter（去重）：Scrapy中用集合实现这个request去重功能，Scrapy中把已经发送的request指纹放入到一个集合中，把下一个request的指纹拿到集合中比对，如果该指纹存在于集合中，说明这个request发送过了，如果没有则继续操作。

3、Item Pipline（管道）：引擎将(Spider返回的)爬取到的Item给Item Pipeline，scrapy-redis 的Item Pipeline将爬取到的 Item 存⼊redis的 items queue。

4、Base Spider（爬虫）：不再使用scrapy原有的Spider类，重写的RedisSpider继承了Spider和RedisMixin这两个类，RedisMixin是用来从redis读取url的类。

Scrapy-Redis 工作机制

image

crapy-redis整体运行流程如下：

• 1. 首先Slaver端从Master端拿任务（Request、url）进行数据抓取，Slaver抓取数据的同时，产生新任务的Request便提交给 Master 处理；（把自己的核心服务器称为master，而把用于跑爬虫程序的机器称为slave）
• 2. Master端只有一个Redis数据库，负责将未处理的Request去重和任务分配，将处理后的Request加入待爬队列，并且存储爬取的数据。

image

Scrapy-Redis默认使用的就是这种策略，我们实现起来很简单，因为任务调度等工作Scrapy-Redis都已经帮我们做好了，我们只需要继承RedisSpider、指定redis_key就行了。缺点是，Scrapy-Redis调度的任务是Request对象，里面信息量比较大（不仅包含url，还有callback函数、headers等信息），可能导致的结果就是会降低爬虫速度、而且会占用Redis大量的存储空间，所以如果要保证效率，那么就需要一定硬件水平。

分布式原理：

• scrapy-redis实现分布式，其实从原理上来说很简单，这里为描述方便，我们把自己的核心服务器称为master，而把用于跑爬虫程序的机器称为slave。

• 采用scrapy框架抓取网页，我们需要首先给定它一些start_urls，爬虫首先访问start_urls里面的url，再根据我们的具体逻辑，对里面的元素、或者是其他的二级、三级页面进行抓取。而要实现分布式，我们只需要在这个starts_urls里面做文章就可以了。

• 我们在master上搭建一个redis数据库（注意这个数据库只用作url的存储，不关心爬取的具体数据），并对每一个需要爬取的网站类型，都开辟一个单独的列表字段。通过设置slave上scrapy-redis获取url的地址为master地址。这样的结果就是，尽管有多个slave，然而大家获取url的地方只有一个，那就是服务器master上的redis数据库。

• 并且，由于scrapy-redis自身的队列机制，slave获取的链接不会相互冲突。这样各个slave在完成抓取任务之后，再把获取的结果汇总到服务器上（这时的数据存储不再在是redis，而是mongodb或者 mysql等存放具体内容的数据库了）

• 这种方法的还有好处就是程序移植性强，只要处理好路径问题，把slave上的程序移植到另一台机器上运行，基本上就是复制粘贴的事情。

url的生成：

• 首先明确一点，url是在master而不是slave上生成的。
• 对于每一个门类的urls（每一个门类对应redis下的一个字段，表示一个url的列表），我们可以单独写一个生成url的脚本。这个脚本要做的事很简单，就是按照我们需要的格式，构造出url并添加到redis里面。
• 对于slave，我们知道，scrapy可以通过Settings来让爬取结束之后不自动关闭，而是不断的去询问队列里有没有新的url，如果有新的url，那么继续获取url并进行爬取。利用这一特性，我们就可以采用控制url的生成的方法，来控制slave爬虫程序的爬取。

定时抓取：

有了上面的介绍，定时抓取的实现就变得简单了，我们只需要定时的去执行url生成的脚本即可。这里推荐linux下的crontab指令，能够非常方便的制定定时任务，具体的介绍大家可以自行查看文档。

程序化管理、web管理：

上述方法虽然能够实现一套完整的流程，但在具体操作过程中还是比较麻烦，可能的话还可以架构web服务器，通过web端来实现url的添加、爬虫状态的监控等，能够减轻非常大的工作量。这些内容如果要展开实在太多，这里就只提一下。

总结：其实对于已有的scrapy程序，对其扩展成分布式程序还是比较容易的。总的来说就是以下几步：

• 找一台高性能服务器，用于redis队列的维护以及数据的存储。

• 扩展scrapy程序，让其通过服务器的redis来获取start_urls，并改写pipeline里数据存储部分，把存储地址改为服务器地址。

• 在服务器上写一些生成url的脚本，并定期执行。

介绍完整个流程，再来介绍一些常见的防抓取屏蔽的方法：

• 设置download_delay，这个方法基本上属于万能的，理论上只要你的delay足够长，网站服务器都没办法判断你是正常浏览还是爬虫。但它带来的副作用也是显然的：大量降低爬取效率。因此这个我们可能需要进行多次测试来得到一个合适的值。有时候download_delay可以设为一个范围随机值。

• 随机生成User-agent：更改User-agent能够防止一些403或者400的错误，基本上属于每个爬虫都会写的。这里我们可以重写scrapy 里的middleware，让程序每次请求都随机获取一个User-agent，增大隐蔽性。具体实现可以参考http://www.sharejs.com/codes/python/8310

• 设置代理IP池：网上有很多免费或收费的代理池，可以借由他们作为中介来爬。一个问题是速度不能保证，第二个问题是，这些代理很多可能本来就没办法用。因此如果要用这个方法，比较靠谱的做法是先用程序筛选一些好用的代理，再在这些代理里面去随机、或者顺序访问。

• 设置好header里面的domain和host，有些网站，比如雪球网会根据这两项来判断请求来源，因此也是要注意的地方。