「如何設計一個大規模分散式網頁爬蟲（Web Crawler / Spider）？」是 Google、Bing 等搜尋引擎以及巨量資料分析公司在系統設計面試中必考的經典硬核題目。
一個優秀的爬蟲系統，絕不僅僅是編寫一個遞迴下載網頁的 Python 腳本。在面對全網數十億個互聯網網頁時，爬蟲系統面臨著一系列極具挑戰性的架構難題：
- 如何防止爬蟲陷入無限迴圈與死鏈陷阱（Spider Traps）？
- 如何實現「禮貌策略（Politeness Policy）」避免把目標網站伺服器打崩？
- 如何在高併發下快速判斷數十億個 URL 是否已經被抓取過（極限去重）？
- 如何在大規模爬蟲節點當機時保證無損容錯？
本文將全方位拆解分散式網頁爬蟲的核心架構與關鍵演算法。
1. 規模估算與設計目標（Scale & Estimation）
- 處理規模：
- 每月抓取目標：10 億（1 Billion）個網頁。
- 平均抓取吞吐量：
1,000,000,000 / (30 * 24 * 3600) ≈ 400 頁/秒（峰值可達 1,000~2,000 頁/秒）。
- 儲存容量：
- 假設平均單一網頁文字與 HTML 體積為 500 KB：
- 每月儲存體積：
1B * 500 KB = 500 TB（5 年累積約 30 PB，需採用大數據分散式物件儲存與冷熱分層）。
2. 分散式爬蟲全鏈路核心架構拓撲
3. 核心設計亮點一：URL Frontier 的「優先級」與「禮貌性」
URL Frontier 是爬蟲的心臟，它必須同時解決兩大矛盾：
3.1 優先級（Priority）：抓取更有價值的網頁
- 採用多個優先級隊列（
F1, F2, …, Fk）。 - 根據網頁的 PageRank 權重、歷史更新頻率與社交媒體熱度，將權重高的 URL 排入高優先級隊列，優先分配下載頻寬。
3.2 禮貌性（Politeness）：防止把目標網站打當機
- 如果一個隊列裡連續排了 1,000 個屬於
apple.com的網頁，爬蟲在 1 秒內併發發起 1,000 次請求，會被目標網站直接判定為 DDoS 攻擊並封鎖 IP。 - Host 佇列隔離與延遲調度：
- 為每個獨立域名（Host）分配一個獨立的 FIFO 佇列。
- 每個 Host 佇列同時只能有 1 個 Worker 執行緒 在抓取。
- Worker 抓取完畢後，強制等待指定的冷卻延遲（例如 1 秒），才能從同一個 Host 佇列中拉取下一個 URL。
4. 核心設計亮點二：極限去重（Deduplication）
爬蟲面對的是百億級別的 URL 與網頁內容，記憶體與儲存極度緊張：
4.1 URL 去重：布隆過濾器（Bloom Filter）
- 如果將 10 億個 URL（平均長度 100 Bytes）全部存入記憶體 HashSet，需要超過 100 GB 記憶體。
- 布隆過濾器：利用多個雜湊函數與點陣圖（BitMap），將 10 億個 URL 的判重記憶體壓縮至 僅需 1~2 GB RAM，在容忍 0.01% 極微誤報率的前提下實現
O(1)的極速判重！
4.2 網頁內容相似度去重：SimHash（局部敏感雜湊）
很多網站存在大量鏡像網頁（內容 99% 相同，僅版權年份或廣告 Banner 不同）：
- 傳統 MD5 只要改動 1 個字元，Hash 值完全劇變。
- SimHash（Locality Sensitive Hashing）：將網頁關鍵詞權重轉換為 64-bit 指紋。如果兩個網頁內容高度相似，其 SimHash 的漢明距離（Hamming Distance
≤ 3） 極小，可在微秒級內識別並剔除重複內容，節省海量儲存。
5. 系統設計面試核心要點
- URL Frontier 雙重調度：清楚區分 Priority Queues（抓取價值）與 Politeness Queues（依 Host 分流與限速）。
- 去重體系完備：URL 層級採用 布隆過濾器，內容層級採用 SimHash。
- 效能防禦健全：內建 DNS 本地快取、Robots.txt 快取、HTML Parser 逾時中斷與 Spider Trap 深度限制（Max Depth = 10）。
- 分散式可擴展性：Kafka 管理 URL Frontier 隊列，無狀態 Fetcher Worker 水平擴展。