聊蜘蛛池的时候，多数人关心的是“今天来了多少蜘蛛”，很少有人盯住另一个指标：同一秒里有多少个请求同时到达。这两个数字在服务器眼里完全是两回事——一天来一万次请求，分散在二十四小时里，和集中在两分钟里，对入口页的压力差着量级。
并发和总抓取量不是一回事
总抓取量决定的是带宽、日志体积和服务器账单；并发决定的是进程、连接、内存和磁盘的瞬时占用。入口页被压垮，通常不是因为一天爬得太多，而是因为某一小段时间里来得太密。
一个很简单的判断方式：翻服务器日志，看相邻几行的时间戳。如果同一秒里能出现几十条入口页请求，说明并发已经上来了；如果每秒只有一两条，那再高的日抓取量也不会太难受。
并发一高，先出问题的地方
- Web 服务器的连接队列：超出 backlog 之后，新连接会被直接丢弃，蜘蛛收到的不是干净的 5xx，而是连接重置，这种反馈对抓取端很不友好。
- 后端处理耗时：入口页如果是动态生成的，每次请求都要查库或拼模板，单请求耗时本就不低；并发一叠加，平均响应时间会被进一步拉长。
- 数据库连接池：池子被占满后请求开始排队，排队又反过来延长每个请求的占用时间，形成正反馈。
- 磁盘与日志写入：同步写日志、每条都刷盘的话，高并发下日志本身就会成为瓶颈。
怎么估一条大致的安全线
纯静态 HTML 的入口页最轻，一台 2 核 4G 的机器，配上合理的 Web 服务器配置，同时扛住几十到一百多个请求通常不成问题。如果每次请求都要走数据库，安全线往往要砍到个位数到十几。
有两点容易算错：一是别拿压测的峰值当日常安全线，压测时没有日志切割、没有备份任务、没有其他站点抢资源；二是要留出余量，把安全线定在实际承载能力的六七成，剩下的留给突发和运维操作。
限速可以做在哪几层
- 用 limit_conn 限制单个 IP 的并发连接数，这比只限请求速率更贴近真实压力。
- 用 limit_req 控制每秒请求数，配合合理的 burst，避免正常波动被误伤。
- 在应用层加一层短时队列，超出的部分快速返回 503 并带上 Retry-After，让抓取端知道可以稍后再来。
- 给不同来源单独设阈值。搜索引擎蜘蛛、普通访客、来源不明的爬虫，不该共用一条规则。
- 持续观察被限速的比例。如果 503 长期占比偏高，说明阈值低于实际承载，要么调高，要么加机器，而不是硬扛。
几个常踩的坑
- 只限总量不限单 IP：额度被一个高频爬虫吃光，其他来源全部被拦。
- 把并发压得极低：蜘蛛等待时间过长，抓取效率明显下降，入口页等于白铺。
- 超时后返回 200 的空页面：抓取端会把空内容当成真实内容处理，比返回 503 更糟。
- 入口页和目标页挤在同一台机器：入口页被打满时，目标页也跟着一起慢，两个环节互相拖累。
并发控制的目标不是挡住蜘蛛，而是让每一只进来的蜘蛛都能拿到一份完整、正常的响应。
落地时可以先做这几步
- 记录一周的基线数据：每秒请求数峰值、平均响应时间、日志里同秒请求的最大条数。
- 按基线设阈值，先宽松一点，观察几天再收紧，别一上来就卡死。
- 能拆就拆：入口页和目标页分开部署，静态资源和动态请求分开处理。
- 每次调完配置后回看日志，确认被限速的到底是哪一类来源，再决定要不要为它单独放宽。
并发这事没有一个通用数字，同样的配置在不同的页面结构、不同的机器规格下差别很大。与其照搬别人的参数，不如先把自己的日志读明白，从真实数据里找那条线。