爬虫的限速与并发控制：令牌桶、漏桶与自适应降速

帮助中心关于爬虫爬虫的限速与并发控制：令牌桶、漏桶与自适应降速

作者：山水代理

发布时间： 2026-11-02 10:31:02

阅读量： 8 人次

限速的目标不是"慢下来"，而是"别触发风控、别浪费请求"

很多采集项目在限速上是两个极端：一是不限，跑得快、被封得也快；二是限得过死，一天跑不完本该半天跑完的量。真正要做的是在"不触发对方风控"的前提下，把可用容量跑满。这需要三个东西：合适的限速模型、清晰的并发控制、以及根据对方反应自动调整的机制。

一、限速到底在限制什么

1、单出口的请求频率
最常被限制的维度。同一个出口 IP 在单位时间内的请求数超过阈值，就会进入慢速通道或被拒。这是限速首先要管的量。

2、在途请求数
同时未返回的请求数。频率不高但在途很多，对目标侧的压力同样存在，也会让本地超时与重试大量堆积。

3、连接建立频率
频繁新建连接本身就是明显特征。能复用就复用，连接建立速率往往比请求速率更容易被识别。

4、访问路径的规律性
严格按顺序、间隔固定、每次都走完整列表，这种规律性比速度更容易暴露。适当打散顺序与间隔，比单纯降速更有效。

二、三种基础限速模型怎么选

1、固定间隔
每次请求后固定等待一段时间。实现最简单，但吞吐被最慢的请求决定，遇到慢响应时整体效率很低。适合请求量小、要求平稳的场景。

2、令牌桶
按固定速率产生令牌，请求消耗令牌，桶里可以攒一定数量的令牌。平均速率被限制，同时允许短时突发把攒下的令牌用掉。适合有突发但又要控制长期平均值的场景。

3、漏桶
请求先进队列，按固定速率流出。输出速率恒定、没有突发，代价是高峰期排队时间变长。适合对目标侧压力必须严格平滑的场景。

4、选择依据是"需不需要突发"
需要在低峰攒量、高峰释放，用令牌桶；需要绝对平滑、宁可排队也不要尖峰，用漏桶；量很小、不在乎效率，固定间隔就够。

三、并发控制不等于限速

1、两个指标要分开设
每秒请求数上限和在途请求数上限是两个独立约束。只限前者，遇到慢响应时在途会堆到很高；只限后者，遇到快响应时会把频率冲上去。两个都要设。

2、按域名分组，不要全局一个值
不同站点能承受的频率差别很大。全局统一限速的结果是对紧的站点太松、对松的站点太紧。按目标域名分别配置，才能各自跑满。

3、按出口分组
限流通常按 IP 生效。多个任务共用同一出口时，各自的配置会被叠加，实际频率远超单任务的设定。出口级别的总配额需要一个统一的地方管。

4、排队要有上限
队列无限增长时，任务会越积越多、延迟越来越高，最终整批超时。给队列设上限，满了宁可拒绝也不能无限排队。

四、自适应降速：按对方反应调整

1、四个观测信号
限流类状态码的比例、响应延迟的分位值、单次返回条数是否变少、验证码或校验页出现的频次。四个指标任何一个异常，都说明当前速率已经偏高。

2、降速要快，恢复要慢
信号出现时立刻按比例降速，信号消失后缓慢回升。反过来做（慢慢降、快速升）会在阈值附近反复试探，反而更容易被判定为异常。

3、降速要加抖动
固定周期、固定幅度地调整，本身也会形成规律。加入随机抖动，避免出现明显的周期性特征。

4、设下限，别一路降到零
持续触发就无限降速，最终等于停跑。设一个下限值，到了下限仍失败就转为切换出口或暂停任务，并告警给人看，而不是自动硬撑。

5、区分"整体慢"与"局部慢"
只有某个域名出问题时，全局降速会拖累其他正常任务。降速粒度应到域名或出口，而不是整个任务一起降。

五、落地要点

1、限速与重试联动
重试请求同样占用配额。失败率高时限速值要相应下调，否则重试会把实际频率推到更高，形成恶性循环。

2、优先队列而不是均分
把更新频繁、价值高的页面放高优先级队列，长尾页面放低优先级。限速收紧时先保高优先级，整体业务受影响最小。

3、指标要能归因
每个请求记录出口、域名、限速档位、耗时。出问题时才能判断是哪个出口、哪个站点、哪一档限速导致，而不是只看总成功率。

4、配置外置，可热调整
限速参数写死在代码里，调整就要发版。放到配置文件或配置中心，出问题时能立即收紧，恢复后再放开。

5、尊重站点声明的规则
站点明确声明的访问规则要遵守。限速不只是技术优化手段，也是采集行为是否可接受的一部分。

总结

限速的本质是把"请求速率"从不可控变成可控。模型上，令牌桶允许突发、漏桶强制平滑、固定间隔最简单；指标上，请求频率与在途请求数要分开设，并按域名和出口分别配置；机制上，要根据状态码、延迟、返回条数与验证频次自适应降速，降得快、升得慢、加抖动、有下限。做到这几点，通常能在不被封的前提下把可用容量跑满。