蜘蛛抓取对站点来说更像一次持续的外部压力测试：它不挑时间、不看业务节奏，只按自己的队列发请求。很多站点在日常流量下一切正常，一旦蜘蛛把抓取并发提上来，响应时间和错误率就同时抬头。这里讨论的不是怎么让蜘蛛多抓，而是抓取高峰来临时，服务器端怎么稳住，别把正常的发现与抓取节奏打断。

抓取高峰暴露的通常不是带宽

带宽往往最先被怀疑，但真正先出问题的通常是下面这些环节：

• 缺少索引或缓存的长尾页查询，单页触发多次数据库访问；
• 动态渲染链路（模板加接口组合）在并发下延迟叠加；
• 单机连接数与进程数上限，请求开始排队；
• 日志写入与磁盘 IO 在抓取密集时拖慢响应。

这些环节平时被低频的用户请求掩盖，蜘蛛一旦对某个栏目、某段分页连续抓取，就会同时把它们压出来。

先把并发量清楚

先从访问日志统计单位时间内的抓取请求数、独立来源数量、状态码分布和响应时间分位（p95、p99）。不要只看总量，要看峰值能持续多久。

• 区分真实蜘蛛与伪装 UA，用反向解析和 IP 段核对来源；
• 观察平均响应时间上升时，抓取并发是否同步上升；
• 找出贡献请求最多的目录与 URL 模式，判断是正常覆盖还是无效路径消耗。

量清楚之后，限速和扩容才有依据，否则很容易把一次正常抓取当成攻击处理。

在入口限速，而不是在应用里硬扛

比较稳妥的做法是在反向代理或网关层对抓取流量做并发与速率限制，让请求排队或快速失败，而不是把压力透传到数据库。

• 按核对过的蜘蛛来源设置单独通道，和普通用户流量分开统计；
• 设置单来源并发上限与每秒请求上限，超出的先排队再拒绝；
• 静态资源、图片、接口与页面分开策略，别让静态文件挤占页面抓取；
• 阈值留出余量，避免抓取正常波动时被误伤。

直接封死某个来源往往得不偿失，一旦是真实蜘蛛，恢复抓取的时间可能比预想的长。

降低单次抓取的成本

• 给列表页、详情页加缓存，缓存命中率是应对抓取峰值最便宜的手段；
• 首屏所需数据尽量一次查询取完，避免一个页面触发几十次数据库访问；
• 抓取触发的写操作（计数、推荐、足迹）要异步化或降级，不让读请求带动写；
• 渲染较重的页面可以做静态化或服务端预渲染，减少每次拼装成本。

宁可少抓，也别返回 5xx

服务器过载时返回 5xx 或连接超时，对抓取节奏的伤害比限速更直接：蜘蛛会退避、降低频率，恢复需要时间。

如果确实需要临时限流，用明确的 429 或 503 并带上 Retry-After，比让请求挂着超时要好。维护窗口内的 503 是合理信号，但不要让它常态化。

把“限速”和“故障”分开表达，蜘蛛才能判断是该等一会儿还是该退出。

监控与容量安排

• 盯住响应时间分位、错误率、活跃连接数和缓存命中率；
• 把抓取请求量和发现、抓取覆盖趋势放在一起看，判断是不是容量问题；
• 发布、改版或大批量新增 URL 前，提前预估抓取增量。

蜘蛛抓取不是一次性事件，而是长期回访。站点要做的不是某天扛住峰值，而是让每次回访都在可预期的资源范围内完成。稳定、可预测的响应，比偶尔一次飞速响应更有价值。