蜘蛛扎堆时，入口頁為什么容易出問题
很多池子平时看起来没問题，一旦某個入口頁被多個蜘蛛同时抓，响應時間立刻從几百毫秒涨到几秒，甚至開始返回 5xx。這類情况往往不是服務器配置太差，而是入口頁本身做得太重，或者同一時間被反复請求时没有做任何缓冲。
蜘蛛的抓取行為有明顯的集中性：發現一批新連結後會短時間内连續請求，尤其入口頁這種被反复指向的地址，很容易成為並發热点。如果每個請求都要查資料库、跑模板、寫一次日誌，压力會被放大好几倍。
压力通常来自這几個地方
- 動態查询：入口頁每次請求都讀資料库、算推荐位、拼装列表。
- 静態资源過多：一個入口頁带上几十個 CSS、JS 和图片，蜘蛛不一定全抓，但浏览器和部分爬虫會拉取。
- 日誌同步寫盘：每個請求都同步寫一次訪問日誌，磁盘 IO 先到瓶颈。
- 缺少缓存：同一個頁面在几秒内被請求几十次，每次都重新生成。
- CDN 回源集中：缓存過期時間设得太短，回源請求全砸到源站。
稳住入口頁的几個做法
先让响應變轻
入口頁的主要职责是被發現和传递連結，不需要承载复杂的交互。把模板里用不到的模块去掉，减少首屏外的资源請求，能省下相当一部分带宽和连接數。一個只包含少量文字和連結的頁面，通常比带一堆组件頁的頁面更容易稳定响應。
缓存與静態化
入口頁内容更新频率不高的话，生成静態 HTML 或加一层頁面缓存是性價比最高的處理方式。CDN 侧把缓存時間设得合理一些，既能减少回源，也不會让更新長期不生效。更新时主動刷新缓存，比把過期時間压到极短更可靠。
日誌和統計別拖後腿
訪問日誌建议异步寫入或先落内存队列，避免單個請求被磁盘拖住。統計類脚本不要放在請求主鏈路里同步执行，能抽样就抽样。日誌本身也要做轮轉和归档，否則文件越大，寫入和排查都越慢。
限速只做兜底，不做主力
robots.txt 里的 crawl-delay 只有部分爬虫會遵守，把它当成唯一的限速手段並不稳妥。更實际的做法是保證頁面足够轻，让即使出現短时並發也不會打满。真要限速，也應该在網關层做连接數控制，而不是靠爬虫自觉。
平时该盯哪些指标
- 入口頁的 TTFB 和整体响應時間分布，不只看平均值。
- 5xx 與超时請求的占比，以及出現的時間段。
- 同时在线连接數和每秒請求數。
- CDN 回源率與缓存命中率。
- 日誌寫入延迟和磁盘使用率。
這些指标不用天天细看，但出現異常时能帮你快速判断是流量問题還是程序問题。比如响應時間涨了而請求數没變，多半是外部依赖或資料库的問题；請求數突然翻倍，則更可能是缓存失效或某個入口頁被集中抓取。
该扩容還是该减量
扩容不是唯一答案。如果入口頁本身很重，加机器只是把問题推後。可以先做頁面瘦身和缓存，再观察指标是否回落；如果确實是因為池子規模扩大带来的正常增長，再考虑加带宽或升配置。反過来，如果長期只有少量蜘蛛来訪，却配了很高的资源，也不划算。
入口頁不需要做成一個功能齐全的網站。它越轻，越不容易在抓取高峰掉鏈子，也越容易排查問题。
稳定的响應比偶尔的爆發更有意义。蜘蛛是否持續来訪，受很多因素影响，但把入口頁做到“随时能打開、打開得快”，至少不會因為服務端問题白白丢掉已经到手的抓取机會。