python爬蟲常見面試題（二）

前言

　　之因此在這裏寫下python爬蟲常見面試題及解答，一是用做筆記，方便往後回憶；二是給本身一個和你們交流的機會，互相學習、進步，但願不正之處你們能給予指正；三是我也是互聯網寒潮下崗的那批人之一，爲了找工做而作準備。

1、題目部分

一、scrapy框架專題部分（不少面試都會涉及到這部分）

（1）請簡要介紹下scrapy框架。

（2）爲何要使用scrapy框架？scrapy框架有哪些優勢？

（3）scrapy框架有哪幾個組件/模塊？簡單說一下工做流程。

（4）scrapy如何實現分佈式抓取？

二、其餘常見問題。

（1）爬蟲使用多線程好？仍是多進程好？爲何？

（2）http和https的區別？

（3）數據結構之堆，棧和隊列的理解和實現。

 

2、解答部分

一、scrapy框架專題部分

（1）請簡要介紹下scrapy框架。

scrapy 是一個快速(fast)、高層次(high-level)的基於 python 的 web 爬蟲構架，用於抓取web站點並從頁面中提取結構化的數據。scrapy 使用了 Twisted異步網絡庫來處理網絡通信。

（2）爲何要使用scrapy框架？scrapy框架有哪些優勢？

• 它更容易構建大規模的抓取項目
• 它異步處理請求，速度很是快
• 它可使用自動調節機制自動調整爬行速度

（3）scrapy框架有哪幾個組件/模塊？簡單說一下工做流程。

Scrapy Engine: 這是引擎，負責Spiders、ItemPipeline、Downloader、Scheduler中間的通信，信號、數據傳遞等等！（像不像人的身體？）

Scheduler(調度器): 它負責接受引擎發送過來的requests請求，並按照必定的方式進行整理排列，入隊、並等待Scrapy Engine(引擎)來請求時，交給引擎。

Downloader（下載器）：負責下載Scrapy Engine(引擎)發送的全部Requests請求，並將其獲取到的Responses交還給Scrapy Engine(引擎)，由引擎交給Spiders來處理，

Spiders：它負責處理全部Responses,從中分析提取數據，獲取Item字段須要的數據，並將須要跟進的URL提交給引擎，再次進入Scheduler(調度器)，

Item Pipeline：它負責處理Spiders中獲取到的Item，並進行處理，好比去重，持久化存儲（存數據庫，寫入文件，總之就是保存數據用的）

Downloader Middlewares（下載中間件）：你能夠看成是一個能夠自定義擴展下載功能的組件

Spider Middlewares（Spider中間件）：你能夠理解爲是一個能夠自定擴展和操做引擎和Spiders中間‘通訊‘的功能組件（好比進入Spiders的Responses;和從Spiders出去的Requests）

 總體架構以下圖：

工做流程：

數據在整個Scrapy的流向：

程序運行的時候，

引擎：Hi！Spider, 你要處理哪個網站？

Spiders：我要處理23wx.com

引擎：你把第一個須要的處理的URL給我吧。

Spiders：給你第一個URL是XXXXXXX.com

引擎：Hi！調度器，我這有request你幫我排序入隊一下。

調度器：好的，正在處理你等一下。

引擎：Hi！調度器，把你處理好的request給我，

調度器：給你，這是我處理好的request

引擎：Hi！下載器，你按照下載中間件的設置幫我下載一下這個request

下載器：好的！給你，這是下載好的東西。（若是失敗：很差意思，這個request下載失敗，而後引擎告訴調度器，這個request下載失敗了，你記錄一下，咱們待會兒再下載。）

引擎：Hi！Spiders，這是下載好的東西，而且已經按照Spider中間件處理過了，你處理一下（注意！這兒responses默認是交給def parse這個函數處理的）

Spiders：（處理完畢數據以後對於須要跟進的URL），Hi！引擎，這是我須要跟進的URL，將它的responses交給函數 def  xxxx(self, responses)處理。還有這是我獲取到的Item。

引擎：Hi ！Item Pipeline 我這兒有個item你幫我處理一下！調度器！這是我須要的URL你幫我處理下。而後從第四步開始循環，直到獲取到你須要的信息，

注意！只有當調度器中不存在任何request了，整個程序纔會中止，（也就是說，對於下載失敗的ＵＲＬ，Scrapy會從新下載。）

以上就是Scrapy整個流程了。

（4）scrapy如何實現分佈式抓取？

能夠藉助scrapy_redis類庫來實現。

在分佈式爬取時，會有master機器和slave機器，其中，master爲核心服務器，slave爲具體的爬蟲服務器。

咱們在master服務器上搭建一個redis數據庫，並將要抓取的url存放到redis數據庫中，全部的slave爬蟲服務器在抓取的時候從redis數據庫中去連接，因爲scrapy_redis自身的隊列機制，slave獲取的url不會相互衝突，而後抓取的結果最後都存儲到數據庫中。master的redis數據庫中還會將抓取過的url的指紋存儲起來，用來去重。相關代碼在dupefilter.py文件中的request_seen()方法中能夠找到。

去重問題： 
dupefilter.py 裏面的源碼： 
def request_seen(self, request): 
fp = request_fingerprint(request) 
added = self.server.sadd(self.key, fp) 
return not added 
去重是把 request 的 fingerprint 存在 redis 上，來實現的。

二、其餘常見問題。

（1）爬蟲使用多線程好？仍是多進程好？爲何？

對於IO密集型代碼（文件處理，網絡爬蟲），多線程可以有效提高效率（單線程下有IO操做會進行IO等待，會形成沒必要要的時間等待，而開啓多線程後，A線程等待時，會自動切換到線程B，能夠不浪費CPU的資源，從而提高程序執行效率）。

在實際的採集過程當中，既考慮網速和相應的問題，也須要考慮自身機器硬件的狀況，來設置多進程或者多線程。

（2）http和https的區別？

A. http是超文本傳輸協議，信息是明文傳輸，https則是具備安全性的ssl加密傳輸協議。

B. http適合於對傳輸速度、安全性要求不是很高，且須要快速開發的應用。如web應用，小的手機遊戲等等。而https適用於任何場景。

（3）數據結構之堆，棧和隊列的理解和實現。

棧（stacks）：棧的特色是後進先出。只能經過訪問一端來實現數據的儲存和檢索的線性數據結構。

隊列（queue）：隊列的特色是先進先出。元素的增長只能在一端，元素的刪除只能在另外一端。增長的一端稱爲隊尾，刪除的一端稱爲隊首。

棧：

1 stack = [1, 2, 3]
2 stack.append(4)
3 stack.append(5)
4 print(stack)
5 stack.pop()
6 stack.pop()
7 print(stack)

輸出結果：

1 [1, 2, 3, 4, 5]
2 [1, 2, 3]

隊列：

1 from collections import deque
2 
3 queue = deque(['Eric', 'John', 'Michael'])
4 queue.append('Terry')
5 queue.append('Graham')
6 print(queue)
7 queue.popleft()
8 print(queue)

輸出結果：

1 deque(['Eric', 'John', 'Michael', 'Terry', 'Graham'])
2 deque(['John', 'Michael', 'Terry', 'Graham'])

這裏還會有一個常見的問題，棧溢出的常見狀況及解決方案。

什麼是棧溢出？

由於棧通常默認爲1-2m，一旦出現死循環或者是大量的遞歸調用，在不斷的壓棧過程當中，形成棧容量超過1m而致使溢出。

棧溢出的幾種狀況？

一、局部數組過大。當函數內部數組過大時，有可能致使堆棧溢出。

二、遞歸調用層次太多。遞歸函數在運行時會執行壓棧操做，當壓棧次數太多時，也會致使堆棧溢出。

 解決方法：

一、用棧把遞歸轉換成非遞歸。

二、增大棧空間。