蜘蛛池的入口頁通常不靠内容取胜，而是靠數量。几百上千個入口頁同时在线，蜘蛛一旦顺着連結批量抓取，請求會在很短時間内集中落到同一批服務器上。這一步没准备好，前面做的 URL 设計、锚文本、返回碼規划，都可能在前几分钟里被打乱节奏。
並發到底從哪来
不少人把蜘蛛抓取想象成匀速慢爬，實际更接近脉冲式：發現在前，抓取在後，而且往往撞在同一個時間窗里。几個叠加因素會把瞬时請求放大：
- 入口頁數量乘以蜘蛛類別數，几十個入口頁配上两三個搜尋引擎，起点就不低；
- 不同搜尋引擎的蜘蛛可能同时工作，高峰互相重叠；
- 入口頁之間如果互相内鏈，蜘蛛一次可以推進多层，請求量成倍增加；
- 同一站群挂在同一台机器或同一 IP 上，等于把所有压力堆在一個出口。
服務器扛不住时會出現什么
最先出現的不是报错，而是變慢：响應時間從几十毫秒涨到几秒。接着才會出現更明确的信号：
- 返回 5xx 或直接超时，蜘蛛记錄為抓取失敗；
- 连接被重置，握手阶段就中断；
- 蜘蛛主動降低抓取频率，甚至暫停對该主机的抓取一段時間。
需要分清楚：這不是「被抓多了被惩罚」，而是资源不足造成的失敗。但结果類似——入口頁被蜘蛛看到的次數變少，後續的 URL 發現自然跟着變慢。
上线前可以做的准备
- 入口頁尽量静態化，避免每個請求都查資料库、跑模板；
- 打開頁面級缓存，設定合理的過期時間，减少重复計算；
- 静態资源與 HTML 分開處理，图片、CSS、JS 交给 CDN 或獨立域名；
- 調整 Web 服務器的最大连接數、队列長度與超时時間，別用預設值硬扛；
- 检查資料库连接池和慢查询，很多「服務器慢」其實卡在資料库這一层。
這些措施的目标不是让並發無限大，而是让峰值来的时候不至于大面积失敗。
限速是双向的
限速不只是限制別人，也是给自己留余量。robots.txt 里的 crawl-delay 並非所有蜘蛛都尊重，因此更可靠的做法是在服務端按 UA 做分流和限流：對已知蜘蛛的請求單獨設定速率，對来源不明的請求做更嚴格的配額。這样即使某個入口頁被集中抓取，也不會把整台机器的资源吃光。
限流要留观察窗口。設定得太紧，蜘蛛拿不到頁面，等同于自己放弃了被發現的机會；設定得太松，又回到過载的老問题。通常建议先按目前承载能力的七成来设，再根據日誌逐步調整。
几個常见誤区
- 並發越大越好：入口頁數量增加並不等于抓取量线性增加，服務器先崩反而會让整体效率下降。
- 入口頁用動態參數：带參數的地址更容易重复抓取，也會让缓存失效，白白消耗资源。
- 不看日誌：狀態碼分布、平均响應時間、峰值 QPS 這些指标是判断是否需要扩容的直接依據，不看就只能靠猜。
- 所有站点共用一台机器：單点故障之外，還容易让一個站的問题波及全部入口頁。
观察與調整的节奏
上线後先看一周日誌，重点看三件事：抓取失敗率、峰值时段、單個入口頁的平均抓取次數。失敗率偏高就先查服務器，而不是急着加入口頁；峰值时段固定，可以考虑错開内容更新和资源發布的時間；單頁抓取次數過低，再回头检查入口頁本身的可達性和内鏈结构。
容量是一步步试出来的，不是一次性配出来的。小步扩容、持續观察，通常比一開始就堆大量入口頁更稳妥。
入口頁的並發准备，本质上是把「蜘蛛愿不愿意来」的前提條件先补齐。服務器稳定，蜘蛛才可能稳定地来；服務器不稳，再多的入口頁也只是增加失敗记錄。