上期我们理性的分析了为什么要学习Scrapy，理由只有一个，那就是免费，一分钱都不用花！
咦？怎么有人扔西红柿？好吧，我承认电视看多了。不过今天是没得看了，为了赶稿，又是一个不眠夜。。。言归正传，我们将在这一期介绍完Scrapy的基础知识， 如果想深入研究，大家可以参考官方文档，那可是出了名的全面，我就不占用公众号的篇幅了。
架构简介
下面是Scrapy的架构，包括组件以及在系统中发生的数据流的概览(红色箭头所示)。 之后会对每个组件做简单介绍，数据流也会做一个简要描述。
组件
Engine: 引擎负责控制数据流在系统中所有组件中流动，并在相应动作发生时触发事件。
Scheduler: 调度器从引擎接受Request并将他们入队，以便之后引擎请求他们时提供给引擎。
Downloader: 下载器负责获取页面数据并提供给引擎，而后提供给Spider。
Spiders: Spider是Scrapy用户编写的用于分析Response并提取Item或提取更多需要下载的URL的类。 每个Spider负责处理特定网站。
Item Pipeline: 负责处理被Spider提取出来的Item。典型的功能有清洗、 验证及持久化操作。
Downloader middlewares: 下载器中间件是在Engine及Downloader之间的特定钩子(specific hooks)，处理Downloader传递给Engine的Response。 其提供了一个简便的机制，通过插入自定义代码来扩展Scrapy功能。
Spider middlewares: 是在Engine及Spider之间的特定钩子(specific hook)，处理Spider的输入(Response)和输出(Items及Requests)。 其提供了一个简便的机制，通过插入自定义代码来扩展Scrapy功能。
数据流
Scrapy中的数据流由执行引擎控制，其过程如下:
Engine从Spider获取第一个需要爬取URL(s)。
Engine用Scheduler调度Requests，并向Scheduler请求下一个要爬取的URL。
Scheduler返回下一个要爬取的URL给Engine。
Engine将URL通过Downloader middlewares转发给Downloader。
一旦页面下载完毕，下载器生成一个该页面的Response，并将其通过Downloader middlewares发送给Engine。
引擎从Downloader中接收到Response并通过Spider middlewares发送给Spider处理。
Spider处理Response并返回爬取到的Item及新的Request给Engine。
Engine将爬取到的Item给Item Pipeline，然后将Request给Scheduler。
从第一步开始重复这个流程，直到Scheduler中没有更多的URLs。
架构就是这样，流程和我第二篇里介绍的迷你架构差不多，但扩展性非常强大。
One more thing
Scrapy基于事件驱动网络框架 Twisted 编写，Twisted是一个异步非阻塞框架。一说到网络通信框架就会提什么同步、异步、阻塞和非阻塞，到底是些啥玩意啊？为啥老是有人暗示或者明示异步=非阻塞？比如Scrapy文档里：Scrapy is written with Twisted, a popular event-driven networking framework for Python. 因此,它的使用代码实现并发性。这种说法对吗?举个栗子:
出场人物:老张,水壶两把(普通水壶,简称水壶;会响的水的壶,简称响水壶)
1。老张把水壶放到火上,立等水开。<强>(同步阻塞)
老张觉得自己有点傻。
2。老张把水壶放到火上,去客厅看电视,时不时去厨房看看水开没有。<强>(同步非阻塞)
老张还是觉得自己有点傻,于是变高端了,买了把会响笛的那种水壶。水开之后,能大声发出嘀~ ~ ~ ~的噪音。
3。老张把响水壶放到火上,立等水开。<强>(异步阻塞)
老张觉得这样傻等意义不大。
4。老张把响水壶放到火上,去客厅看电视,水壶响之前不再去看它了,响了再去拿壶。<强>(异步非阻塞)
老张觉得自己聪明了。
所谓同步异步,只是对于水壶而言。普通水壶,同步;响水壶,异步。虽然都能干的活,但响水壶可以在自己完工之后,提示老张水开了。这是普通水壶所不能及的。同步只能让调用者去轮询自己(情况2中),造成老张效率的低下。
