3. Scrapy的數(shù)據(jù)流（Data Flow）

Scrapy中的數(shù)據(jù)流由執(zhí)行引擎控制，下面的原文摘自Scrapy官網(wǎng)，我根據(jù)猜測做了點評，為進一步開發(fā)GooSeeker開源爬蟲指示方向：

The Engine gets the first URLs to crawl from the Spider and schedules
them in the Scheduler, as Requests.

URL誰來準備呢？看樣子是Spider自己來準備，那么可以猜測Scrapy架構部分（不包括Spider）主要做事件調度，不管網(wǎng)址的存儲?？雌饋眍愃艷ooSeeker會員中心的爬蟲羅盤，為目標網(wǎng)站準備一批網(wǎng)址，放在羅盤中準備執(zhí)行爬蟲調度操作。所以，這個開源項目的下一個目標是把URL的管理放在一個集中的調度庫里面

The Engine asks the Scheduler for the next URLs to crawl.

看到這里其實挺難理解的，要看一些其他文檔才能理解透。接第1點，引擎從Spider中把網(wǎng)址拿到以后，封裝成一個Request，交給了事件循環(huán)，會被Scheduler收來做調度管理的，暫且理解成對Request做排隊。引擎現(xiàn)在就找Scheduler要接下來要下載的網(wǎng)頁地址

The Scheduler returns the next URLs to crawl to the Engine and the
Engine sends them to the Downloader, passing through the Downloader
Middleware (request direction).

從調度器申請任務，把申請到的任務交給下載器，在下載器和引擎之間有個下載器中間件，這是作為一個開發(fā)框架的必備亮點，開發(fā)者可以在這里進行一些定制化擴展

Once the page finishes downloading the Downloader generates a Response
(with that page) and sends it to the Engine, passing through the
Downloader Middleware (response direction).

下載完成了，產(chǎn)生一個Response，通過下載器中間件交給引擎。注意，Response和前面的Request的首字母都是大寫，雖然我還沒有看其它Scrapy文檔，但是我猜測這是Scrapy框架內部的事件對象，也可以推測出是一個異步的事件驅動的引擎，對于高性能、低開銷引擎來說，這是必須的

The Engine receives the Response from the Downloader and sends it to
the Spider for processing, passing through the Spider Middleware
(input direction).

再次出現(xiàn)一個中間件，給開發(fā)者足夠的發(fā)揮空間

The Spider processes the Response and returns scraped items and new
Requests (to follow) to the Engine.

每個Spider順序抓取一個個網(wǎng)頁，完成一個就構造另一個Request事件，開始另一個網(wǎng)頁的抓取

The Engine passes scraped items and new Requests returned by a spider
through Spider Middleware (output direction), and then sends processed
items to Item Pipelines and processed Requests to the Scheduler.

引擎作事件分發(fā)

The process repeats (from step 1) until there are no more requests
from the Scheduler.

持續(xù)不斷地運行

4. 接下來的工作

接下來，我們將進一步研讀Scrapy的文檔，實現(xiàn)GooSeeker開源Python爬蟲與Scrapy的集成

5. 文檔修改歷史

2016-06-11：V1.0，首次發(fā)布

原文來自：SegmentFault