以前寫過一篇使用python爬蟲抓站的一些技巧總結，總結了諸多爬蟲使用的方法；那篇東東現在看來還是挺有用的，但是當時很菜（現在也菜，但是比那時進步了不少），很多東西都不是很優，屬於”只是能用”這麼個層次。這篇進階篇打算把“能用”提升到“用得省事省心”這個層次。
一、gzip/deflate支援
現在的網頁普遍支援gzip壓縮，這往往可以解決大量傳輸時間，以VeryCD的主頁為例，未壓縮版本247K，壓縮了以後45K，為原來的1/5。這就意味著抓取速度會快5倍。
然而python的urllib/urllib2預設都不支援壓縮，要返回壓縮格式，必須在request的header裡面寫明’accept-encoding’，然後讀取response後更要檢查header檢視是否有’content-encoding’一項來判斷是否需要解碼，很繁瑣瑣碎。如何讓urllib2自動支援gzip, defalte呢？
其實可以繼承BaseHanlder類，然後build_opener的方式來處理：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 |
import urllib2 from gzip import GzipFile from StringIO import StringIO class ContentEncodingProcessor(urllib2.BaseHandler): """A handler to add gzip capabilities to urllib2 requests """ # add headers to requests def http_request(self, req): req.add_header("Accept-Encoding", "gzip, deflate") return req # decode def http_response(self, req, resp): old_resp = resp # gzip if resp.headers.get("content-encoding") == "gzip": gz = GzipFile( fileobj=StringIO(resp.read()), mode="r" ) resp = urllib2.addinfourl(gz, old_resp.headers, old_resp.url, old_resp.code) resp.msg = old_resp.msg # deflate if resp.headers.get("content-encoding") == "deflate": gz = StringIO( deflate(resp.read()) ) resp = urllib2.addinfourl(gz, old_resp.headers, old_resp.url, old_resp.code) # 'class to add info() and resp.msg = old_resp.msg return resp # deflate support import zlib def deflate(data): # zlib only provides the zlib compress format, not the deflate format; try: # so on top of all there's this workaround: return zlib.decompress(data, -zlib.MAX_WBITS) except zlib.error: return zlib.decompress(data) |
然後就簡單了，
|
1 2 3 4 5 |
encoding_support = ContentEncodingProcessor opener = urllib2.build_opener( encoding_support, urllib2.HTTPHandler ) #直接用opener開啟網頁，如果伺服器支援gzip/defalte則自動解壓縮 content = opener.open(url).read() |
二、更方便地多執行緒
總結一文的確提及了一個簡單的多執行緒模板，但是那個東東真正應用到程式裡面去只會讓程式變得支離破碎，不堪入目。在怎麼更方便地進行多執行緒方面我也動了一番腦筋。先想想怎麼進行多執行緒呼叫最方便呢？
1、用twisted進行非同步I/O抓取
事實上更高效的抓取並非一定要用多執行緒，也可以使用非同步I/O法：直接用twisted的getPage方法，然後分別加上非同步I/O結束時的callback和errback方法即可。例如可以這麼幹：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 |
from twisted.web.client import getPage from twisted.internet import reactor links = [ 'http://www.verycd.com/topics/%d/'%i for i in range(5420,5430) ] def parse_page(data,url): print len(data),url def fetch_error(error,url): print error.getErrorMessage(),url # 批量抓取連結 for url in links: getPage(url,timeout=5) \ .addCallback(parse_page,url) \ #成功則呼叫parse_page方法 .addErrback(fetch_error,url) #失敗則呼叫fetch_error方法 reactor.callLater(5, reactor.stop) #5秒鐘後通知reactor結束程式 reactor.run() |
twisted人如其名，寫的程式碼實在是太扭曲了，非正常人所能接受，雖然這個簡單的例子看上去還好；每次寫twisted的程式整個人都扭曲了，累得不得了，文件等於沒有，必須得看原始碼才知道怎麼整，唉不提了。
如果要支援gzip/deflate，甚至做一些登陸的擴充套件，就得為twisted寫個新的HTTPClientFactory類諸如此類，我這眉頭真是大皺，遂放棄。有毅力者請自行嘗試。
這篇講怎麼用twisted來進行批量網址處理的文章不錯，由淺入深，深入淺出，可以一看。
2、設計一個簡單的多執行緒抓取類
還是覺得在urllib之類python“本土”的東東里面折騰起來更舒服。試想一下，如果有個Fetcher類，你可以這麼呼叫
|
1 2 3 4 5 6 |
f = Fetcher(threads=10) #設定下載執行緒數為10 for url in urls: f.push(url) #把所有url推入下載佇列 while f.taskleft(): #若還有未完成下載的執行緒 content = f.pop() #從下載完成佇列中取出結果 do_with(content) # 處理content內容 |
這麼個多執行緒呼叫簡單明瞭，那麼就這麼設計吧，首先要有兩個佇列，用Queue搞定，多執行緒的基本架構也和“技巧總結”一文類似，push方法和pop方法都比較好處理，都是直接用Queue的方法，taskleft則是如果有“正在執行的任務”或者”佇列中的任務”則為是，也好辦，於是程式碼如下：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 |
import urllib2 from threading import Thread,Lock from Queue import Queue import time class Fetcher: def __init__(self,threads): self.opener = urllib2.build_opener(urllib2.HTTPHandler) self.lock = Lock() #執行緒鎖 self.q_req = Queue() #任務佇列 self.q_ans = Queue() #完成佇列 self.threads = threads for i in range(threads): t = Thread(target=self.threadget) t.setDaemon(True) t.start() self.running = 0 def __del__(self): #解構時需等待兩個佇列完成 time.sleep(0.5) self.q_req.join() self.q_ans.join() def taskleft(self): return self.q_req.qsize()+self.q_ans.qsize()+self.running def push(self,req): self.q_req.put(req) def pop(self): return self.q_ans.get() def threadget(self): while True: req = self.q_req.get() with self.lock: #要保證該操作的原子性，進入critical area self.running += 1 try: ans = self.opener.open(req).read() except Exception, what: ans = '' print what self.q_ans.put((req,ans)) with self.lock: self.running -= 1 self.q_req.task_done() time.sleep(0.1) # don't spam if __name__ == "__main__": links = [ 'http://www.verycd.com/topics/%d/'%i for i in range(5420,5430) ] f = Fetcher(threads=10) for url in links: f.push(url) while f.taskleft(): url,content = f.pop() print url,len(content) |
三、一些瑣碎的經驗
1、連線池：
opener.open和urllib2.urlopen一樣，都會新建一個http請求。通常情況下這不是什麼問題，因為線性環境下，一秒鐘可能也就新生成一個請求；然而在多執行緒環境下，每秒鐘可以是幾十上百個請求，這麼幹只要幾分鐘，正常的有理智的伺服器一定會封禁你的。
然而在正常的html請求時，保持同時和伺服器幾十個連線又是很正常的一件事，所以完全可以手動維護一個HttpConnection的池，然後每次抓取時從連線池裡面選連線進行連線即可。
這裡有一個取巧的方法，就是利用squid做代理伺服器來進行抓取，則squid會自動為你維護連線池，還附帶資料快取功能，而且squid本來就是我每個伺服器上面必裝的東東，何必再自找麻煩寫連線池呢。
2、設定執行緒的棧大小
棧大小的設定將非常顯著地影響python的記憶體佔用，python多執行緒不設定這個值會導致程式佔用大量記憶體，這對openvz的vps來說非常致命。stack_size必須大於32768，實際上應該總要32768*2以上
|
1 2 |
from threading import stack_size stack_size(32768*16) |
3、設定失敗後自動重試
|
1 2 3 4 5 6 7 8 9 10 11 12 |
def get(self,req,retries=3): try: response = self.opener.open(req) data = response.read() except Exception , what: print what,req if retries>0: return self.get(req,retries-1) else: print 'GET Failed',req return '' return data |
4、設定超時
|
1 2 |
import socket socket.setdefaulttimeout(10) #設定10秒後連線超時 |
5、登陸
登陸更加簡化了，首先build_opener中要加入cookie支援，參考“總結”一文；如要登陸VeryCD，給Fetcher新增一個空方法login，並在__init__()中呼叫，然後繼承Fetcher類並override login方法：
|
1 2 3 4 5 6 7 8 9 |
def login(self,username,password): import urllib data=urllib.urlencode({'username':username, 'password':password, 'continue':'http://www.verycd.com/', 'login_submit':u'登入'.encode('utf-8'), 'save_cookie':1,}) url = 'http://www.verycd.com/signin' self.opener.open(url,data).read() |
於是在Fetcher初始化時便會自動登入VeryCD網站。
四、總結
如此，把上述所有小技巧都糅合起來就和我目前的私藏最終版的Fetcher類相差不遠了，它支援多執行緒，gzip/deflate壓縮，超時設定，自動重試，設定棧大小，自動登入等功能；程式碼簡單，使用方便，效能也不俗，可謂居家旅行，殺人放火，咳咳，之必備工具。
之所以說和最終版差得不遠，是因為最終版還有一個保留功能“馬甲術”：多代理自動選擇。看起來好像僅僅是一個random.choice的區別，其實包含了代理獲取，代理驗證，代理測速等諸多環節，這就是另一個故事了。