1. 瓶頸在哪別急著加線程先看清多線程爬蟲(chóng)的真相很多剛開(kāi)始寫(xiě)爬蟲(chóng)的朋友一遇到采集速度慢第一反應(yīng)就是“上多線程”。這個(gè)思路本身沒(méi)錯(cuò)但問(wèn)題在于如果不搞清楚多線程到底優(yōu)化了什么、沒(méi)優(yōu)化什么那很可能開(kāi)了一堆線程速度不升反降甚至被目標(biāo)網(wǎng)站封了IP整個(gè)采集任務(wù)直接報(bào)廢。我先說(shuō)結(jié)論P(yáng)ython多線程爬蟲(chóng)的性能優(yōu)化核心不在于“多用幾個(gè)線程”而在于讓線程真正忙起來(lái)。你需要先想清楚一個(gè)問(wèn)題——你的爬蟲(chóng)當(dāng)前的時(shí)間到底花在哪里。如果是花在等待網(wǎng)絡(luò)響應(yīng)上多線程確實(shí)有效如果是花在CPU計(jì)算上那多線程不僅沒(méi)幫助還會(huì)因?yàn)镚IL鎖拖慢速度。這一步判斷錯(cuò)后面所有優(yōu)化方案都是空中樓閣。這里就要提到Python里一個(gè)繞不開(kāi)的概念GILGlobal Interpreter Lock全局解釋器鎖。通俗點(diǎn)講GIL保證了同一個(gè)進(jìn)程里同一時(shí)刻只有一個(gè)線程在執(zhí)行Python字節(jié)碼。所以如果你的爬蟲(chóng)主要是在做CPU密集型的計(jì)算比如對(duì)每一篇抓下來(lái)的HTML做復(fù)雜的正則匹配、用大量的邏輯判斷去解析字段那么多線程并不會(huì)讓這些計(jì)算并行執(zhí)行。真正要加速這種場(chǎng)景應(yīng)該考慮多進(jìn)程或者直接換工具。那多線程爬蟲(chóng)到底優(yōu)化了什么呢答案是IO等待時(shí)間。網(wǎng)絡(luò)請(qǐng)求發(fā)出后CPU一直在等待響應(yīng)返回。這個(gè)等待過(guò)程不占用GIL——在真正的IO等待期間Python會(huì)釋放GIL讓其他線程有機(jī)會(huì)執(zhí)行。也就是說(shuō)多線程爬蟲(chóng)的價(jià)值在于當(dāng)某一個(gè)請(qǐng)求正在等待網(wǎng)絡(luò)的毫秒級(jí)延遲時(shí)另外的線程可以去發(fā)起新的請(qǐng)求、處理已經(jīng)返回的數(shù)據(jù)。這樣整體上就把看似零散的等待時(shí)間拼了起來(lái)單位時(shí)間內(nèi)能發(fā)出去的請(qǐng)求自然變多了。明白了這層原理再看網(wǎng)上那些“線程數(shù)拉到50”“并發(fā)開(kāi)200”的配置就知道有多危險(xiǎn)了。開(kāi)多少線程合適要看你的目標(biāo)網(wǎng)站響應(yīng)速度、你本機(jī)的性能、以及爬蟲(chóng)單次請(qǐng)求的業(yè)務(wù)邏輯復(fù)雜度。盲目開(kāi)太多線程CPU切換線程的成本會(huì)陡增目標(biāo)服務(wù)器也可能直接把你拉黑得不償失。2. 基礎(chǔ)優(yōu)化線程池、任務(wù)隊(duì)列與請(qǐng)求會(huì)話的正確姿勢(shì)2.1 線程數(shù)量到底開(kāi)多少合適先給一個(gè)參考公式。假設(shè)目標(biāo)網(wǎng)站單次響應(yīng)耗時(shí)是 (T_r)本地解析和寫(xiě)數(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ī)上下文切換的開(kāi)銷(xiāo)實(shí)際使用中我會(huì)在這個(gè)理論值基礎(chǔ)上乘以1.2到1.5的安全系數(shù)。不過(guò)說(shuō)實(shí)話公式只是起步參考真正靠譜的辦法是從低到高逐步壓測(cè)。先把線程數(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ù)。我見(jiàn)過(guò)太多人一上來(lái)就開(kāi)50個(gè)線程抓一個(gè)小網(wǎng)站結(jié)果目標(biāo)服務(wù)器響應(yīng)從200ms被打到2秒錯(cuò)誤率飆升。爬蟲(chóng)不是拉滿就是好細(xì)水長(zhǎng)流才是長(zhǎng)久之計(jì)。2.2 線程池比手動(dòng)創(chuàng)建線程靠譜得多多線程爬蟲(chóng)最忌諱的做法是每個(gè)請(qǐng)求都手動(dòng)創(chuàng)建新線程。假設(shè)你要采集10萬(wàn)條數(shù)據(jù)每條都threading.Thread(...).start()那就意味著系統(tǒng)需要?jiǎng)?chuàng)建和銷(xiāo)毀10萬(wàn)個(gè)線程。每次創(chuàng)建線程都要申請(qǐng)內(nèi)存、初始化運(yùn)行時(shí)環(huán)境銷(xiāo)毀時(shí)還要回收資源這些開(kāi)銷(xiāo)加起來(lái)非?？捎^而且線程數(shù)量一旦失控系統(tǒng)調(diào)度壓力陡增爬蟲(chóng)性能反而會(huì)直線下降。正確的方案是用線程池把線程的生命周期統(tǒng)一管理起來(lái)。Python自帶的concurrent.futures.ThreadPoolExecutor就夠用了簡(jiǎn)單、沒(méi)有額外依賴(lài)適合絕大多數(shù)采集場(chǎng)景。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é)果比如寫(xiě)庫(kù)、寫(xiě)文件 except Exception as e: print(f請(qǐng)求失敗: {url}, 錯(cuò)誤: {e})with語(yǔ)句會(huì)在代碼塊結(jié)束時(shí)自動(dòng)調(diào)用shutdown(waitTrue)優(yōu)雅地等待所有線程完成任務(wù)。這個(gè)細(xì)節(jié)很重要它避免了主線程提前退出導(dǎo)致子線程任務(wù)被強(qiáng)殺的問(wèn)題。寫(xiě)爬蟲(chóng)跑批任務(wù)時(shí)我踩過(guò)好幾次這種坑主線程里的任務(wù)提交完了直接退出結(jié)果半數(shù)的請(qǐng)求還沒(méi)回來(lái)程序就結(jié)束了。2.3 任務(wù)隊(duì)列緩沖區(qū)的藝術(shù)線程池解決了線程生命周期管理問(wèn)題但還需要考慮任務(wù)分發(fā)。如果你的采集任務(wù)是一個(gè)動(dòng)態(tài)列表——比如先抓列表頁(yè)拿到一批詳情頁(yè)URL之后再去抓詳情頁(yè)——那光靠固定列表就不夠用了。這時(shí)需要引入生產(chǎn)者消費(fèi)者模式。queue.Queue是標(biāo)準(zhǔn)庫(kù)自帶的任務(wù)隊(duì)列特點(diǎn)是線程安全多線程同時(shí)往里塞數(shù)據(jù)、取數(shù)據(jù)都不會(huì)出問(wèn)題。整體結(jié)構(gòu)上可以分成三層生產(chǎn)者負(fù)責(zé)把待抓取的URL放進(jìn)隊(duì)列工作線程從隊(duì)列里取URL去請(qǐng)求和解析消費(fèi)者負(fù)責(zé)把解析結(jié)果落庫(kù)或?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ì)列長(zhǎng)度要限制用maxsize設(shè)置一個(gè)合理上限。如果隊(duì)列無(wú)窮大生產(chǎn)者速度遠(yuǎn)快于消費(fèi)者內(nèi)存會(huì)被待處理URL擠爆。二是要設(shè)置哨兵值比如None來(lái)通知工作線程退出不給的話所有線程會(huì)永遠(yuǎn)卡在task_queue.get()上主程序退不干凈。三是task_done()與join()配合只有所有任務(wù)都標(biāo)記完成queue.join()才會(huì)返回這能確保退出前所有任務(wù)都真正處理完了。2.4 請(qǐng)求會(huì)話復(fù)用每個(gè)線程一個(gè)專(zhuān)屬連接爬蟲(chóng)一旦上了多線程很多人都會(huì)遇到一個(gè)奇怪的現(xiàn)象單線程時(shí)請(qǐng)求很正常一開(kāi)多線程頻繁出現(xiàn)連接被重置、socket超時(shí)。排查到最后發(fā)現(xiàn)問(wèn)題往往出在Session的使用方式上。requests.Session內(nèi)部維護(hù)了TCP連接池可以復(fù)用底層連接減少每次請(qǐng)求時(shí)三次握手和TLS握手的開(kāi)銷(xiāo)。但如果多個(gè)線程共享同一個(gè)Session連接池的并發(fā)競(jìng)爭(zhēng)會(huì)導(dǎo)致連接狀態(tài)混亂反而觸發(fā)各種奇怪的網(wǎng)絡(luò)錯(cuò)誤。正確的姿勢(shì)是每個(gè)線程一個(gè)Session或者至少保證Session的創(chuàng)建和線程綁定。在ThreadPoolExecutor場(chǎng)景下可以用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的線程安全問(wèn)題又讓連接池真正發(fā)揮作用。從實(shí)測(cè)效果來(lái)看無(wú)論是目標(biāo)響應(yīng)速度還是本地資源占用這個(gè)改動(dòng)帶來(lái)的提升都相當(dāng)明顯。2.5 超時(shí)與重試不給僵尸線程留機(jī)會(huì)多線程爬蟲(chóng)最怕的一個(gè)場(chǎng)景某個(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í)連接建立超過(guò)3.05秒就放棄第二個(gè)值是讀取超時(shí)數(shù)據(jù)包間隔超過(guò)10秒就放棄。設(shè)置超時(shí)之后還要配合重試機(jī)制。重試不是簡(jiǎn)單地重來(lái)一遍而是要有退避策略——第一次失敗后等1秒第二次等2秒逐步放大間隔避免在目標(biāo)服務(wù)器還沒(méi)恢復(fù)時(shí)用高并發(fā)反復(fù)沖擊把自己送進(jìn)封禁名單。requests庫(kù)本身不支持自動(dòng)重試需要借助requests.adapters.HTTPAdapter來(lái)注入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)求過(guò)多也納入重試范圍。目標(biāo)服務(wù)器返回429就是在告訴你“慢一點(diǎn)”此時(shí)退避重試是最正確的應(yīng)對(duì)方式大部分情況下能夠平穩(wěn)渡過(guò)限流窗口。3. 性能黑洞與瓶頸排查從日志到數(shù)據(jù)每一分鐘都花在刀刃上3.1 數(shù)據(jù)解析優(yōu)化容易被忽略的大頭不少爬蟲(chóng)在優(yōu)化時(shí)只顧著調(diào)線程數(shù)忘了看數(shù)據(jù)解析環(huán)節(jié)的耗時(shí)。這里有個(gè)真實(shí)的模擬場(chǎng)景某個(gè)采集任務(wù)需要抓取商品列表每個(gè)列表頁(yè)20個(gè)商品。最初所有解析邏輯都用BeautifulSoup的find_all配合CSS選擇器把整個(gè)HTML先轉(zhuǎn)成復(fù)雜的對(duì)象樹(shù)再反復(fù)查詢(xún)。單個(gè)頁(yè)面解析耗時(shí)接近120ms對(duì)于每秒要處理幾十個(gè)頁(yè)面的爬蟲(chóng)這部分CPU計(jì)算量就很可觀了。而且要強(qiáng)調(diào)一點(diǎn)解析是純CPU計(jì)算前面講過(guò)GIL的限制這部分計(jì)算在多線程下不會(huì)并行加速。也就是說(shuō)線程開(kāi)得越多每個(gè)線程分到的CPU時(shí)間片反而越少整體吞吐甚至可能下降。所以數(shù)據(jù)解析優(yōu)化往往是爬蟲(chóng)性能提升空間最大的環(huán)節(jié)。常見(jiàn)的優(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è)模擬頁(yè)面做對(duì)比測(cè)試BeautifulSoup方案耗時(shí)約120ms換etree.HTML加X(jué)Path之后單頁(yè)解析大概25ms提升接近5倍。這還是小頁(yè)面如果遇到幾千行的大HTML差距會(huì)更夸張。這個(gè)優(yōu)化本質(zhì)上不改變線程數(shù)量但每個(gè)線程能處理的頁(yè)面數(shù)大幅上升整體吞吐自然就上去了。3.2 序列化與存儲(chǔ)把“寫(xiě)”變成異步操作解析完成之后的數(shù)據(jù)要去哪里如果每次解析完都直接寫(xiě)數(shù)據(jù)庫(kù)或?qū)懳募@個(gè)寫(xiě)操作會(huì)阻塞當(dāng)前線程。尤其是寫(xiě)入數(shù)據(jù)庫(kù)的場(chǎng)景如果使用同步連接一次插入就算只要幾毫秒在成千上萬(wàn)次請(qǐng)求的積累下阻塞時(shí)間也相當(dāng)可觀。更合理的設(shè)計(jì)是把數(shù)據(jù)寫(xiě)入做成異步?？梢杂靡粋€(gè)單獨(dú)的消費(fèi)者線程把解析結(jié)果放進(jìn)另一個(gè)隊(duì)列由專(zhuān)門(mén)的存儲(chǔ)線程批量處理。批量插入比逐條插入的效率高得多還能減少數(shù)據(jù)庫(kù)連接建立和事務(wù)提交的開(kāi)銷(xiāo)。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()這里把寫(xiě)庫(kù)放到了獨(dú)立線程中抓取線程只需要把數(shù)據(jù)塞進(jìn)隊(duì)列就能立刻返回繼續(xù)抓取下一個(gè)頁(yè)面。雖然看起來(lái)只是把阻塞從抓取線程轉(zhuǎn)移到了存儲(chǔ)線程但效果完全不同抓取線程不再被磁盤(pán)或數(shù)據(jù)庫(kù)拖慢系統(tǒng)整體吞吐量由生產(chǎn)和消費(fèi)之間的平衡決定而不受最慢環(huán)節(jié)的制約。3.3 請(qǐng)求耗時(shí)與并發(fā)收益的可視化優(yōu)化過(guò)程中有一個(gè)操作我建議所有爬蟲(chóng)開(kāi)發(fā)者都做打印一份請(qǐng)求耗時(shí)分布統(tǒng)計(jì)。不用多復(fù)雜的工具最簡(jiǎn)單的就是按耗時(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í)際跑下來(lái)每秒只有12個(gè)左右因?yàn)槟切?00ms的尖峰請(qǐng)求拖慢了整條流水線。這類(lèi)情況下先減少單次請(qǐng)求的傳輸量、優(yōu)化請(qǐng)求頭、啟用壓縮傳輸往往比單純加線程更有效。3.4 常見(jiàn)性能問(wèn)題速查表現(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ù)超過(guò)目標(biāo)服務(wù)器承載壓測(cè)找到拐點(diǎn)降低線程數(shù)增加退避重試任務(wù)跑著跑著卡住某請(qǐng)求長(zhǎng)期無(wú)響應(yīng)檢查是否有請(qǐng)求沒(méi)設(shè)超時(shí)設(shè)置連接超時(shí)和讀取超時(shí)增加重試內(nèi)存持續(xù)上漲隊(duì)列中堆積大量未處理數(shù)