蜘蛛扎堆时，入口页为什么容易出问题

很多池子平时看起来没问题，一旦某个入口页被多个蜘蛛同时抓，响应时间立刻从几百毫秒涨到几秒，甚至开始返回 5xx。这类情况往往不是服务器配置太差，而是入口页本身做得太重，或者同一时间被反复请求时没有做任何缓冲。

蜘蛛的抓取行为有明显的集中性：发现一批新链接后会短时间内连续请求，尤其入口页这种被反复指向的地址，很容易成为并发热点。如果每个请求都要查数据库、跑模板、写一次日志，压力会被放大好几倍。

压力通常来自这几个地方

• 动态查询：入口页每次请求都读数据库、算推荐位、拼装列表。
• 静态资源过多：一个入口页带上几十个 CSS、JS 和图片，蜘蛛不一定全抓，但浏览器和部分爬虫会拉取。
• 日志同步写盘：每个请求都同步写一次访问日志，磁盘 IO 先到瓶颈。
• 缺少缓存：同一个页面在几秒内被请求几十次，每次都重新生成。
• CDN 回源集中：缓存过期时间设得太短，回源请求全砸到源站。

稳住入口页的几个做法

先让响应变轻

入口页的主要职责是被发现和传递链接，不需要承载复杂的交互。把模板里用不到的模块去掉，减少首屏外的资源请求，能省下相当一部分带宽和连接数。一个只包含少量文字和链接的页面，通常比带一堆组件页的页面更容易稳定响应。

缓存与静态化

入口页内容更新频率不高的话，生成静态 HTML 或加一层页面缓存是性价比最高的处理方式。CDN 侧把缓存时间设得合理一些，既能减少回源，也不会让更新长期不生效。更新时主动刷新缓存，比把过期时间压到极短更可靠。

日志和统计别拖后腿

访问日志建议异步写入或先落内存队列，避免单个请求被磁盘拖住。统计类脚本不要放在请求主链路里同步执行，能抽样就抽样。日志本身也要做轮转和归档，否则文件越大，写入和排查都越慢。

限速只做兜底，不做主力

robots.txt 里的 crawl-delay 只有部分爬虫会遵守，把它当成唯一的限速手段并不稳妥。更实际的做法是保证页面足够轻，让即使出现短时并发也不会打满。真要限速，也应该在网关层做连接数控制，而不是靠爬虫自觉。

平时该盯哪些指标

• 入口页的 TTFB 和整体响应时间分布，不只看平均值。
• 5xx 与超时请求的占比，以及出现的时间段。
• 同时在线连接数和每秒请求数。
• CDN 回源率与缓存命中率。
• 日志写入延迟和磁盘使用率。

这些指标不用天天细看，但出现异常时能帮你快速判断是流量问题还是程序问题。比如响应时间涨了而请求数没变，多半是外部依赖或数据库的问题；请求数突然翻倍，则更可能是缓存失效或某个入口页被集中抓取。

该扩容还是该减量

扩容不是唯一答案。如果入口页本身很重，加机器只是把问题推后。可以先做页面瘦身和缓存，再观察指标是否回落；如果确实是因为池子规模扩大带来的正常增长，再考虑加带宽或升配置。反过来，如果长期只有少量蜘蛛来访，却配了很高的资源，也不划算。

入口页不需要做成一个功能齐全的网站。它越轻，越不容易在抓取高峰掉链子，也越容易排查问题。

稳定的响应比偶尔的爆发更有意义。蜘蛛是否持续来访，受很多因素影响，但把入口页做到“随时能打开、打开得快”，至少不会因为服务端问题白白丢掉已经到手的抓取机会。