直接從數據流的角度來說比較容易理解：

·1、Spider創建一個初識url請求，把這個請求通過Engine轉給Scheduler調度模塊。然後Scheduler向Engine提供一個請求（這個請求是一個真實的url請求）

疑問點一：為什麽Engine把請求發給Scheduler模塊，然後又從Scheduler模塊裏面取出來，這不是多此一舉麽，這個Scheduler模塊有作用麽？

按照我的理解，scrapy把各個組件模塊化，就是為了更加方便的配置，當然你把所有模塊都寫在一起，功能同樣可以實現，只不過這就失去了這個框架的價值了，Scheduler就是為了存取請求，而Spider就是解析出新的請求和數據item。

疑問點二：為什麽說Scheduler存的是真實的url請求

Spider裏面的url不一定是我們需要的url，需要經過解析，生成我們所需要的真實url，然後通過Engine發送給Scheduler

2、第一步Engine已經得到了真實的url地址，然後Engine把這個請求request發送給Downloader模塊

tips：我們主要到Engine發送請求給Downloader模塊前，需要進過DownloaderMiddleware中間件，實際上這裏可以對請求做一些修改，也就是添加User-Agent之類的參數，如果用過requests第三方包應該容易理解

3、Downloader模塊把網頁下載完成後會把結果返回給Engine

tips：這個過程同樣會經過DownloaderMiddleware，所以很容易理解，我們可以在這裏修改response相關信息

4、Engine得到數據之後，它會把數據發送給Spider進行解析得到item（數據）或者是request（新的請求）

tips：比如我們本來要獲取的是圖片信息，在得到的response中發現不止有圖片信息（item），還有其他的連接（新的request）

5、Spider解析得到的item和request會有兩種走向

a：如果是item，也就是已經得到了數據，那麽就通過Engine把item發送到Itempipeline進行處理，這裏主要是進行數據的清洗、查重、保存等操作。

b：如果生成的是request，照著之前的，通過Engine把真實請求request發送給Scheduler，然後Engine從Scheduler拿request，發給給Downloader下載，Downloader下載完通過Engine發送給Spider。。如此往復，直到沒有新的request請求

有時候看到網上的教程那麽長會覺得難，不想去學，真正去學的時候會發現，其實也就那樣。好了，關於scrapy的數據流就到這。

scrapy詳細數據流走向（個人總結）