聊蜘蛛池的时候，多數人關心的是“今天来了多少蜘蛛”，很少有人盯住另一個指标：同一秒里有多少個請求同时到達。這两個數字在服務器眼里完全是两回事——一天来一萬次請求，分散在二十四小时里，和集中在两分钟里，對入口頁的压力差着量級。
並發和總抓取量不是一回事
總抓取量决定的是带宽、日誌体积和服務器帳單；並發决定的是進程、连接、内存和磁盘的瞬时占用。入口頁被压垮，通常不是因為一天爬得太多，而是因為某一小段時間里来得太密。
一個很简單的判断方式：翻服務器日誌，看相邻几行的時間戳。如果同一秒里能出現几十條入口頁請求，說明並發已经上来了；如果每秒只有一两條，那再高的日抓取量也不會太难受。
並發一高，先出問题的地方
- Web 服務器的连接队列：超出 backlog 之後，新连接會被直接丢弃，蜘蛛收到的不是干净的 5xx，而是连接重置，這種反馈對抓取端很不友好。
- 後端處理耗时：入口頁如果是動態生成的，每次請求都要查库或拼模板，單請求耗时本就不低；並發一叠加，平均响應時間會被進一步拉長。
- 資料库连接池：池子被占满後請求開始排队，排队又反過来延長每個請求的占用時間，形成正反馈。
- 磁盘與日誌寫入：同步寫日誌、每條都刷盘的话，高並發下日誌本身就會成為瓶颈。
怎么估一條大致的安全线
纯静態 HTML 的入口頁最轻，一台 2 核 4G 的机器，配上合理的 Web 服務器配置，同时扛住几十到一百多個請求通常不成問题。如果每次請求都要走資料库，安全线往往要砍到個位數到十几。
有两点容易算错：一是別拿压测的峰值当日常安全线，压测时没有日誌切割、没有备份任務、没有其他站点抢资源；二是要留出余量，把安全线定在實际承载能力的六七成，剩下的留给突發和运维操作。
限速可以做在哪几层
- 用 limit_conn 限制單個 IP 的並發连接數，這比只限請求速率更贴近真實压力。
- 用 limit_req 控制每秒請求數，配合合理的 burst，避免正常波動被誤伤。
- 在應用层加一层短时队列，超出的部分快速返回 503 並带上 Retry-After，让抓取端知道可以稍後再来。
- 给不同来源單獨设阈值。搜尋引擎蜘蛛、普通訪客、来源不明的爬虫，不该共用一條規則。
- 持續观察被限速的比例。如果 503 長期占比偏高，說明阈值低于實际承载，要么調高，要么加机器，而不是硬扛。
几個常踩的坑
- 只限總量不限單 IP：額度被一個高频爬虫吃光，其他来源全部被拦。
- 把並發压得极低：蜘蛛等待時間過長，抓取效率明顯下降，入口頁等于白铺。
- 超时後返回 200 的空頁面：抓取端會把空内容当成真實内容處理，比返回 503 更糟。
- 入口頁和目标頁挤在同一台机器：入口頁被打满时，目标頁也跟着一起慢，两個环节互相拖累。
並發控制的目标不是挡住蜘蛛，而是让每一只進来的蜘蛛都能拿到一份完整、正常的响應。
落地时可以先做這几步
- 记錄一周的基线資料：每秒請求數峰值、平均响應時間、日誌里同秒請求的最大條數。
- 按基线设阈值，先宽松一点，观察几天再收紧，別一上来就卡死。
- 能拆就拆：入口頁和目标頁分開部署，静態资源和動態請求分開處理。
- 每次調完配置後回看日誌，確認被限速的到底是哪一類来源，再决定要不要為它單獨放宽。
並發這事没有一個通用數字，同样的配置在不同的頁面结构、不同的机器規格下差別很大。與其照搬別人的參數，不如先把自己的日誌讀明白，從真實資料里找那條线。