1. 瓶頸在哪別急著加線程先看清多線程爬蟲的真相很多剛開始寫爬蟲的朋友一遇到采集速度慢第一反應(yīng)就是“上多線程”。這個(gè)思路本身沒錯(cuò)但問題在于如果不搞清楚多線程到底優(yōu)化了什么、沒優(yōu)化什么那很可能開了一堆線程速度不升反降甚至被目標(biāo)網(wǎng)站封了IP整個(gè)采集任務(wù)直接報(bào)廢。我先說結(jié)論P(yáng)ython多線程爬蟲的性能優(yōu)化核心不在于“多用幾個(gè)線程”而在于讓線程真正忙起來。你需要先想清楚一個(gè)問題——你的爬蟲當(dāng)前的時(shí)間到底花在哪里。如果是花在等待網(wǎng)絡(luò)響應(yīng)上多線程確實(shí)有效如果是花在CPU計(jì)算上那多線程不僅沒幫助還會(huì)因?yàn)镚IL鎖拖慢速度。這一步判斷錯(cuò)后面所有優(yōu)化方案都是空中樓閣。這里就要提到Python里一個(gè)繞不開的概念GILGlobal Interpreter Lock全局解釋器鎖。通俗點(diǎn)講GIL保證了同一個(gè)進(jìn)程里同一時(shí)刻只有一個(gè)線程在執(zhí)行Python字節(jié)碼。所以如果你的爬蟲主要是在做CPU密集型的計(jì)算比如對(duì)每一篇抓下來的HTML做復(fù)雜的正則匹配、用大量的邏輯判斷去解析字段那么多線程并不會(huì)讓這些計(jì)算并行執(zhí)行。真正要加速這種場景應(yīng)該考慮多進(jìn)程或者直接換工具。那多線程爬蟲到底優(yōu)化了什么呢答案是IO等待時(shí)間。網(wǎng)絡(luò)請(qǐng)求發(fā)出后CPU一直在等待響應(yīng)返回。這個(gè)等待過程不占用GIL——在真正的IO等待期間Python會(huì)釋放GIL讓其他線程有機(jī)會(huì)執(zhí)行。也就是說多線程爬蟲的價(jià)值在于當(dāng)某一個(gè)請(qǐng)求正在等待網(wǎng)絡(luò)的毫秒級(jí)延遲時(shí)另外的線程可以去發(fā)起新的請(qǐng)求、處理已經(jīng)返回的數(shù)據(jù)。這樣整體上就把看似零散的等待時(shí)間拼了起來單位時(shí)間內(nèi)能發(fā)出去的請(qǐng)求自然變多了。明白了這層原理再看網(wǎng)上那些“線程數(shù)拉到50”“并發(fā)開200”的配置就知道有多危險(xiǎn)了。開多少線程合適要看你的目標(biāo)網(wǎng)站響應(yīng)速度、你本機(jī)的性能、以及爬蟲單次請(qǐng)求的業(yè)務(wù)邏輯復(fù)雜度。盲目開太多線程CPU切換線程的成本會(huì)陡增目標(biāo)服務(wù)器也可能直接把你拉黑得不償失。2. 基礎(chǔ)優(yōu)化線程池、任務(wù)隊(duì)列與請(qǐng)求會(huì)話的正確姿勢2.1 線程數(shù)量到底開多少合適先給一個(gè)參考公式。假設(shè)目標(biāo)網(wǎng)站單次響應(yīng)耗時(shí)是 (T_r)本地解析和寫數(shù)據(jù)耗時(shí)是 (T_p)那么單個(gè)線程完成一個(gè)請(qǐng)求的周期大約是 (T_r T_p)。如果我們希望本機(jī)每秒發(fā)出 (N) 個(gè)請(qǐng)求那么理論上需要的線程數(shù)大約是[ 線程數(shù) \approx N \times (T_r T_p) ]舉個(gè)例子目標(biāo)接口平均響應(yīng)200ms本地解析加存儲(chǔ)大概需要50ms一個(gè)請(qǐng)求完整體驗(yàn)是250ms。如果你希望每秒發(fā)出20個(gè)請(qǐng)求那差不多需要 (20 \times 0.25 5) 個(gè)線程。當(dāng)然這只是理論值還要考慮網(wǎng)絡(luò)抖動(dòng)、目標(biāo)服務(wù)器限流、本機(jī)上下文切換的開銷實(shí)際使用中我會(huì)在這個(gè)理論值基礎(chǔ)上乘以1.2到1.5的安全系數(shù)。不過說實(shí)話公式只是起步參考真正靠譜的辦法是從低到高逐步壓測。先把線程數(shù)設(shè)成2穩(wěn)定跑一分鐘觀察每秒請(qǐng)求數(shù)和錯(cuò)誤率再逐步升到4、8、16直到出現(xiàn)響應(yīng)變慢或錯(cuò)誤增多的拐點(diǎn)那個(gè)拐點(diǎn)附近就是這臺(tái)機(jī)器、這個(gè)目標(biāo)站點(diǎn)的合理線程數(shù)。我見過太多人一上來就開50個(gè)線程抓一個(gè)小網(wǎng)站結(jié)果目標(biāo)服務(wù)器響應(yīng)從200ms被打到2秒錯(cuò)誤率飆升。爬蟲不是拉滿就是好細(xì)水長流才是長久之計(jì)。2.2 線程池比手動(dòng)創(chuàng)建線程靠譜得多多線程爬蟲最忌諱的做法是每個(gè)請(qǐng)求都手動(dòng)創(chuàng)建新線程。假設(shè)你要采集10萬條數(shù)據(jù)每條都threading.Thread(...).start()那就意味著系統(tǒng)需要?jiǎng)?chuàng)建和銷毀10萬個(gè)線程。每次創(chuàng)建線程都要申請(qǐng)內(nèi)存、初始化運(yùn)行時(shí)環(huán)境銷毀時(shí)還要回收資源這些開銷加起來非?？捎^而且線程數(shù)量一旦失控系統(tǒng)調(diào)度壓力陡增爬蟲性能反而會(huì)直線下降。正確的方案是用線程池把線程的生命周期統(tǒng)一管理起來。Python自帶的concurrent.futures.ThreadPoolExecutor就夠用了簡單、沒有額外依賴適合絕大多數(shù)采集場景。from concurrent.futures import ThreadPoolExecutor, as_completed def fetch_one(url): # 實(shí)際的請(qǐng)求和解析邏輯 return url, data urls [https://example.com/item/1, https://example.com/item/2, ...] # 合理設(shè)置線程數(shù)這里以8為例 with ThreadPoolExecutor(max_workers8) as executor: future_map {executor.submit(fetch_one, url): url for url in urls} for future in as_completed(future_map): url future_map[future] try: result future.result() # 處理結(jié)果比如寫庫、寫文件 except Exception as e: print(f請(qǐng)求失敗: {url}, 錯(cuò)誤: {e})with語句會(huì)在代碼塊結(jié)束時(shí)自動(dòng)調(diào)用shutdown(waitTrue)優(yōu)雅地等待所有線程完成任務(wù)。這個(gè)細(xì)節(jié)很重要它避免了主線程提前退出導(dǎo)致子線程任務(wù)被強(qiáng)殺的問題。寫爬蟲跑批任務(wù)時(shí)我踩過好幾次這種坑主線程里的任務(wù)提交完了直接退出結(jié)果半數(shù)的請(qǐng)求還沒回來程序就結(jié)束了。2.3 任務(wù)隊(duì)列緩沖區(qū)的藝術(shù)線程池解決了線程生命周期管理問題但還需要考慮任務(wù)分發(fā)。如果你的采集任務(wù)是一個(gè)動(dòng)態(tài)列表——比如先抓列表頁拿到一批詳情頁URL之后再去抓詳情頁——那光靠固定列表就不夠用了。這時(shí)需要引入生產(chǎn)者消費(fèi)者模式。queue.Queue是標(biāo)準(zhǔn)庫自帶的任務(wù)隊(duì)列特點(diǎn)是線程安全多線程同時(shí)往里塞數(shù)據(jù)、取數(shù)據(jù)都不會(huì)出問題。整體結(jié)構(gòu)上可以分成三層生產(chǎn)者負(fù)責(zé)把待抓取的URL放進(jìn)隊(duì)列工作線程從隊(duì)列里取URL去請(qǐng)求和解析消費(fèi)者負(fù)責(zé)把解析結(jié)果落庫或?qū)懳募?。import queue import threading task_queue queue.Queue(maxsize200) # 生產(chǎn)者不斷往隊(duì)列里放URL def producer(url_list): for url in url_list: task_queue.put(url) # 消費(fèi)者工作線程從隊(duì)列取URL并抓取 def worker(): while True: url task_queue.get() if url is None: # 哨兵值用于退出循環(huán) break try: fetch_url(url) finally: task_queue.task_done()有幾個(gè)細(xì)節(jié)值得注意。一是隊(duì)列長度要限制用maxsize設(shè)置一個(gè)合理上限。如果隊(duì)列無窮大生產(chǎn)者速度遠(yuǎn)快于消費(fèi)者內(nèi)存會(huì)被待處理URL擠爆。二是要設(shè)置哨兵值比如None來通知工作線程退出不給的話所有線程會(huì)永遠(yuǎn)卡在task_queue.get()上主程序退不干凈。三是task_done()與join()配合只有所有任務(wù)都標(biāo)記完成queue.join()才會(huì)返回這能確保退出前所有任務(wù)都真正處理完了。2.4 請(qǐng)求會(huì)話復(fù)用每個(gè)線程一個(gè)專屬連接爬蟲一旦上了多線程很多人都會(huì)遇到一個(gè)奇怪的現(xiàn)象單線程時(shí)請(qǐng)求很正常一開多線程頻繁出現(xiàn)連接被重置、socket超時(shí)。排查到最后發(fā)現(xiàn)問題往往出在Session的使用方式上。requests.Session內(nèi)部維護(hù)了TCP連接池可以復(fù)用底層連接減少每次請(qǐng)求時(shí)三次握手和TLS握手的開銷。但如果多個(gè)線程共享同一個(gè)Session連接池的并發(fā)競爭會(huì)導(dǎo)致連接狀態(tài)混亂反而觸發(fā)各種奇怪的網(wǎng)絡(luò)錯(cuò)誤。正確的姿勢是每個(gè)線程一個(gè)Session或者至少保證Session的創(chuàng)建和線程綁定。在ThreadPoolExecutor場景下可以用threading.local()為每個(gè)線程保存獨(dú)立的Session實(shí)例import threading import requests thread_local threading.local() def get_session(): if not hasattr(thread_local, session): thread_local.session requests.Session() thread_local.session.headers.update({ User-Agent: Mozilla/5.0 (compatible; MySpider/1.0) }) return thread_local.session這樣每個(gè)線程只會(huì)創(chuàng)建一次Session后續(xù)所有請(qǐng)求都復(fù)用線程內(nèi)的TCP連接既避免了共享Session的線程安全問題又讓連接池真正發(fā)揮作用。從實(shí)測效果來看無論是目標(biāo)響應(yīng)速度還是本地資源占用這個(gè)改動(dòng)帶來的提升都相當(dāng)明顯。2.5 超時(shí)與重試不給僵尸線程留機(jī)會(huì)多線程爬蟲最怕的一個(gè)場景某個(gè)請(qǐng)求永遠(yuǎn)不返回線程在那里干等什么活也不干。如果一個(gè)工作線程被一個(gè)超時(shí)未響應(yīng)的請(qǐng)求卡住幾分鐘那這個(gè)線程的吞吐貢獻(xiàn)基本就歸零了。更麻煩的是如果一個(gè)進(jìn)程里有多個(gè)線程同時(shí)被不同請(qǐng)求卡住整個(gè)任務(wù)會(huì)越跑越慢看著像是卡死了實(shí)際上是在等超時(shí)。標(biāo)準(zhǔn)做法是在請(qǐng)求層設(shè)置明確的超時(shí)時(shí)間并且區(qū)分連接超時(shí)和讀取超時(shí)session.get(url, timeout(3.05, 10))這個(gè)元組里第一個(gè)值是連接超時(shí)連接建立超過3.05秒就放棄第二個(gè)值是讀取超時(shí)數(shù)據(jù)包間隔超過10秒就放棄。設(shè)置超時(shí)之后還要配合重試機(jī)制。重試不是簡單地重來一遍而是要有退避策略——第一次失敗后等1秒第二次等2秒逐步放大間隔避免在目標(biāo)服務(wù)器還沒恢復(fù)時(shí)用高并發(fā)反復(fù)沖擊把自己送進(jìn)封禁名單。requests庫本身不支持自動(dòng)重試需要借助requests.adapters.HTTPAdapter來注入urllib3的Retry策略from requests.adapters import HTTPAdapter from urllib3.util.retry import Retry retry_strategy Retry( total3, # 最多重試3次 backoff_factor1, # 退避時(shí)間1s, 2s, 4s status_forcelist[429, 500, 502, 503, 504], allowed_methods[GET, POST], ) adapter HTTPAdapter(max_retriesretry_strategy, pool_connections10, pool_maxsize10) session get_session() session.mount(http://, adapter) session.mount(https://, adapter)需要注意status_forcelist里加429是指定HTTP 429請(qǐng)求過多也納入重試范圍。目標(biāo)服務(wù)器返回429就是在告訴你“慢一點(diǎn)”此時(shí)退避重試是最正確的應(yīng)對(duì)方式大部分情況下能夠平穩(wěn)渡過限流窗口。3. 性能黑洞與瓶頸排查從日志到數(shù)據(jù)每一分鐘都花在刀刃上3.1 數(shù)據(jù)解析優(yōu)化容易被忽略的大頭不少爬蟲在優(yōu)化時(shí)只顧著調(diào)線程數(shù)忘了看數(shù)據(jù)解析環(huán)節(jié)的耗時(shí)。這里有個(gè)真實(shí)的模擬場景某個(gè)采集任務(wù)需要抓取商品列表每個(gè)列表頁20個(gè)商品。最初所有解析邏輯都用BeautifulSoup的find_all配合CSS選擇器把整個(gè)HTML先轉(zhuǎn)成復(fù)雜的對(duì)象樹再反復(fù)查詢。單個(gè)頁面解析耗時(shí)接近120ms對(duì)于每秒要處理幾十個(gè)頁面的爬蟲這部分CPU計(jì)算量就很可觀了。而且要強(qiáng)調(diào)一點(diǎn)解析是純CPU計(jì)算前面講過GIL的限制這部分計(jì)算在多線程下不會(huì)并行加速。也就是說線程開得越多每個(gè)線程分到的CPU時(shí)間片反而越少整體吞吐甚至可能下降。所以數(shù)據(jù)解析優(yōu)化往往是爬蟲性能提升空間最大的環(huán)節(jié)。常見的優(yōu)化路線是“從重到輕”如果有明確規(guī)律的數(shù)據(jù)優(yōu)先用正則表達(dá)式或字符串切片處理如果需要處理復(fù)雜嵌套的HTML用lxml的etree.HTML配合XPath性能比BeautifulSoup高一個(gè)數(shù)量級(jí)只有確實(shí)需要容錯(cuò)性很強(qiáng)的解析時(shí)才保留BeautifulSoup并且盡量用lxml作為底層解析器即在BeautifulSoup(markup, lxml)中指定解析引擎。from lxml import etree def parse_item(html): tree etree.HTML(html) # XPath提取標(biāo)題 title tree.xpath(//h1[classitem-title]/text()) # XPath提取價(jià)格 price tree.xpath(//span[classprice]/text()) return title[0].strip() if title else , price[0].strip() if price else 拿同一個(gè)模擬頁面做對(duì)比測試BeautifulSoup方案耗時(shí)約120ms換etree.HTML加XPath之后單頁解析大概25ms提升接近5倍。這還是小頁面如果遇到幾千行的大HTML差距會(huì)更夸張。這個(gè)優(yōu)化本質(zhì)上不改變線程數(shù)量但每個(gè)線程能處理的頁面數(shù)大幅上升整體吞吐自然就上去了。3.2 序列化與存儲(chǔ)把“寫”變成異步操作解析完成之后的數(shù)據(jù)要去哪里如果每次解析完都直接寫數(shù)據(jù)庫或?qū)懳募@個(gè)寫操作會(huì)阻塞當(dāng)前線程。尤其是寫入數(shù)據(jù)庫的場景如果使用同步連接一次插入就算只要幾毫秒在成千上萬次請(qǐng)求的積累下阻塞時(shí)間也相當(dāng)可觀。更合理的設(shè)計(jì)是把數(shù)據(jù)寫入做成異步?？梢杂靡粋€(gè)單獨(dú)的消費(fèi)者線程把解析結(jié)果放進(jìn)另一個(gè)隊(duì)列由專門的存儲(chǔ)線程批量處理。批量插入比逐條插入的效率高得多還能減少數(shù)據(jù)庫連接建立和事務(wù)提交的開銷。import sqlite3 import queue store_queue queue.Queue(maxsize500) store_thread_stop threading.Event() def store_worker(): conn sqlite3.connect(data.db) cur conn.cursor() batch_size 50 while not store_thread_stop.is_set(): batch [] # 批量取出最多50條 for _ in range(batch_size): try: item store_queue.get_nowait() batch.append(item) except queue.Empty: break if batch: cur.executemany( INSERT INTO items(url, title, price) VALUES(?, ?, ?), batch ) conn.commit() else: store_thread_stop.wait(0.5) # 隊(duì)列空時(shí)短暫休眠 store_thread threading.Thread(targetstore_worker) store_thread.start()這里把寫庫放到了獨(dú)立線程中抓取線程只需要把數(shù)據(jù)塞進(jìn)隊(duì)列就能立刻返回繼續(xù)抓取下一個(gè)頁面。雖然看起來只是把阻塞從抓取線程轉(zhuǎn)移到了存儲(chǔ)線程但效果完全不同抓取線程不再被磁盤或數(shù)據(jù)庫拖慢系統(tǒng)整體吞吐量由生產(chǎn)和消費(fèi)之間的平衡決定而不受最慢環(huán)節(jié)的制約。3.3 請(qǐng)求耗時(shí)與并發(fā)收益的可視化優(yōu)化過程中有一個(gè)操作我建議所有爬蟲開發(fā)者都做打印一份請(qǐng)求耗時(shí)分布統(tǒng)計(jì)。不用多復(fù)雜的工具最簡單的就是按耗時(shí)區(qū)間分組記錄請(qǐng)求數(shù)量比如0-100ms、100-200ms、200-500ms、500ms以上各有多少請(qǐng)求。跑一批樣本請(qǐng)求后你會(huì)看到耗時(shí)分布呈現(xiàn)什么形態(tài)這比猜要準(zhǔn)得多。舉個(gè)實(shí)際例子某個(gè)模擬抓取任務(wù)目標(biāo)接口平均耗時(shí)180ms但高耗時(shí)區(qū)間有一些尖峰達(dá)到800ms甚至1秒。如果按平均耗時(shí)180ms計(jì)算5個(gè)線程一秒鐘大約能完成25個(gè)請(qǐng)求。但實(shí)際跑下來每秒只有12個(gè)左右因?yàn)槟切?00ms的尖峰請(qǐng)求拖慢了整條流水線。這類情況下先減少單次請(qǐng)求的傳輸量、優(yōu)化請(qǐng)求頭、啟用壓縮傳輸往往比單純加線程更有效。3.4 常見性能問題速查表現(xiàn)象可能原因排查思路解決方案線程增多但吞吐不升解析邏輯密集GIL限制用profile工具統(tǒng)計(jì)CPU時(shí)間占比優(yōu)化解析代碼考慮多進(jìn)程頻繁connection reset多個(gè)線程共享一個(gè)Session查看是否有人為共享Session用threading.local實(shí)現(xiàn)每線程獨(dú)立Session請(qǐng)求大量超時(shí)線程數(shù)超過目標(biāo)服務(wù)器承載壓測找到拐點(diǎn)降低線程數(shù)增加退避重試任務(wù)跑著跑著卡住某請(qǐng)求長期無響應(yīng)檢查是否有請(qǐng)求沒設(shè)超時(shí)設(shè)置連接超時(shí)和讀取超時(shí)增加重試內(nèi)存持續(xù)上漲隊(duì)列中堆積大量未處理數(shù)