Scrapy的爬取原理

为什么要用Scrapy框架呢？因为框架可以帮我们把一些常用的功能集成了，我们只需要调用即可。比如下载模块就不需要再写了，只需要提供要下载的链接地址，专注于提取数据就好。

而且框架使用了异步的模式，也就是说，我们发出了HTTP请求以后，不需要等待Web服务器返回成功，而是继续执行其他的操作 ，不会浪费这段时间，效率自然就上去了。使用这种框架，我们就不需要自己去实现它了。

基本原理

下面来说一下基本原理。Scrapy的架构中主要有如下几种角色：

• engine：引擎 ，主要是负责其他组件的通信、数据传递等。
• Scheduler：调度器，负责接受引擎发来的requests请求，并放入消息队列里面，等待engine来取出。
• Downloader：下载器，负责下载Engine发来的requests请求，并将responses返回给Engine
• Spider：负责处理Responses，分析出数据，获取Item字段的数据，并将需要跟进的URL提交给Engine，再次进入Scheduler
• Item Pipeline：负责处理Spider中获取到的Item，并进行去重、存储等处理。
• Downloader Middlewares：下载中间件，可以自定义，用来扩展下载功能。
• Spider Middlewares：Spider中间件，可以自定义，用来扩展Engine与 Spiders中间通信的功能组件。

简单的讲，

• Engine就是一个协调者，所有的请求、回复都需要它来转发。也可以说它就类似于整个系统的CPU，用来指挥的。

• Scheduler：就是一个消息队列，将Engine发来的请求排队。类似于缓存。为什么会需要这样一个Scheduler存在，因为进行页面下载是需要时间的，在这段时间里面其他组件不应该闲着，但是请求又源源不断的来，所以可以放到这个缓存里面，等上一个请求处理完了，就由Engine从队列里面取一个请求继续执行。

• Downloader是真正干活的，它不断接收请求，并从远端进行下载，然后又将收到的回复返回给Engine。

• Spider：是对收到的HTTP响应进行处理的，根据预设的规则提取相应的字段。同时它还有另一个作用就是确定下一个需要下载的URL是什么。

• Item Pipeline：也是一个干活的，不过Downloader是对外，Item PipeLine是对内的，它主要是在后台进行数据的进一步操作比如去重、存储等。

基本流程

image.png

因为引擎是总指挥，所以它会问Spider要处理的网站的URL、以及返回的responses是交给那个函数进行处理，然后引擎会让调度器将请求放入消息队列中。

然后引擎每次都从调度器里面取一个请求发给下载器，由下载器执行具体的下载操作。

如果下载成功，则直接返回引擎
如果下载失败，引擎还会告诉调度器待会再下一次。

下载得到的responses默认交给parse函数进行处理，我们还可以定义另外parse函数进行具体的处理操作。

Spider提取Item，然后告诉引擎下一个需要处理的URL是什么。

同时PipeLine也会将Items存放到数据库中。