很多人看服务器日志时会有个直观感受：蜘蛛来的时候不是一条一条慢慢抓，而是一小会儿涌进来一批请求。这背后就是抓取并发。理解并发，比只盯着“今天来了多少次”更有用，因为它直接决定了蜘蛛单位时间里能拿走多少页面，也决定了你的服务器会不会被自己招来的流量压出 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 被及时发现，先把最基本的响应稳定性做好，通常比任何技巧都更有效。