很多人看服務器日誌时會有個直观感受：蜘蛛来的时候不是一條一條慢慢抓，而是一小會儿涌進来一批請求。這背後就是抓取並發。理解並發，比只盯着“今天来了多少次”更有用，因為它直接决定了蜘蛛單位時間里能拿走多少頁面，也决定了你的服務器會不會被自己招来的流量压出 5xx。
蜘蛛不是單线程的訪客
主流搜尋引擎的抓取系統會為同一個站点维護一定數量的並行连接。具体數字不公開，也會随站点情况動態調整：站点响應快、错誤少，並發可能被調高；站点经常超时或返回 5xx，並發會被往下压，甚至整体降低抓取频率。
這意味着抓取量並不是由你提交了多少 URL 决定的，而是由蜘蛛愿意分配的並發 × 每次請求的耗时共同决定的。頁面速度在這里的意义，不只是用戶体驗。
服務器變慢时，蜘蛛會先缩手
当响應時間從 200 毫秒涨到 2 秒，在同样的並發下，單位時間能抓完的 URL 會掉一個數量級左右。更麻烦的是超时：
- 连接超时、讀超时會让這次抓取算作失敗，URL 需要重新排队；
- 连續失敗會让抓取系統認為站点不稳定，主動降速；
- 降速之後，新發布的 URL 被發現的時間會被拉長。
抓取失敗的代價不只是這一次没抓到，而是让蜘蛛對整個站点的稳定性评價下降，恢复速度往往比下降速度慢得多。
429 和 503：主動告诉蜘蛛慢一点
如果某個時間段服務器确實吃紧，與其让請求超时，不如明确返回狀態碼：
- 503 Service Unavailable：临时不可用，配合 Retry-After 响應头更清晰；
- 429 Too Many Requests：請求過多，适合用在站内搜尋、篩選接口這類容易被打爆的路径上。
要注意，這两個狀態碼用得太频繁也有代價：長期大面积返回，會被理解為站点整体不可用，抓取频率會持續走低。它适合当應急阀，不适合当常態。
带宽和响應時間，哪個更關键
不少人以為抓取压力主要是带宽問题，實际上大多數中小站点卡在响應時間而不是带宽。原因在于蜘蛛的並發是按“同时開着的连接”算的，一個慢查询占着连接不释放，就等于占着一個抓取名額。常见的拖慢因素：
- 未加缓存的動態查询，尤其是列表頁、标簽頁；
- 頁面上同步加载的第三方統計、字体、广告脚本；
- 資料库连接池過小，請求在服務端排队；
- 图片、CSS 等静態资源没走 CDN，和 HTML 抢同一台机器的出口。
把静態资源挪走、给動態頁加一层頁面缓存，往往比單纯升級带宽更能提升單位時間被抓走的 URL 數。
從日誌里看並發带来的問题
不需要复杂工具，先看三件事：
- 同一秒内蜘蛛請求數的峰值是多少，是否和你的告警時間点重合；
- 抓取請求的响應時間分布，慢的那部分集中在哪些 URL 模板；
- 5xx 是否集中在某個時間段或某個功能模块。
如果發現蜘蛛高峰總撞上後台的批處理任務，可以考虑把重任務挪開，或者给蜘蛛訪問频繁的路径做更积极的缓存。
几点實操建议
- 缩短首字节時間優先于压缩頁面体积，前者對並發效率的影响更直接；
- 對站内搜尋、篩選參數頁這類近乎無限的 URL 入口，在 robots 或狀態碼层面做节制；
- 不要把並發理解成来得越多越好，错誤的 URL 被高並發抓走，只會浪費服務器和抓取配額；
- 观察趋势而不是單日數字，抓取量下降通常先出現在响應時間上。
抓取並發和服務器承载本质上是同一件事的两面：站点越稳、越快，蜘蛛越敢多抓；站点越抖，它越保守。想让更多 URL 被及时發現，先把最基本的响應稳定性做好，通常比任何技巧都更有效。