代理IP的并发控制与限流算法：从漏桶到令牌桶的工程实践

帮助中心代理知识代理IP的并发控制与限流算法：从漏桶到令牌桶的工程实践

作者：山水代理

发布时间： 2026-05-14 15:33:22

阅读量： 11 人次

并发不是越高越好：不科学的并发控制等于自杀式攻击

很多爬虫开发者认为，并发数越高、代理IP池越大，采集速度就越快。但在实际运行中，过高的并发往往导致代理IP被批量封禁、目标网站响应变慢、甚至触发DDoS级别的防御。根本原因在于缺少科学的并发控制与限流机制。限流不是限制你的能力，而是保护你的业务稳定性。本文从工程角度，讲解两种经典的限流算法——漏桶和令牌桶，以及它们在代理IP环境中的具体实现方法。

一、为什么需要限流？

代理IP场景下的限流有两个层面的含义：
1. 对目标网站的限流：避免单个IP或整体请求频率超过目标网站允许的阈值，触发429（Too Many Requests）或封禁。
2. 对代理服务商的限流：很多代理套餐规定了每秒最大请求数（QPS），超过限制会导致API提取失败或IP被服务商临时降级。

没有限流的爬虫就像没有刹车片的汽车——短时间可能跑得很快，但随时会撞墙。合理的限流策略可以在保证采集效率的同时，将封禁风险降到最低。

二、限流算法一：固定窗口计数器（最简单但最不推荐）

固定窗口计数器是最简单的限流算法：在每个时间窗口（如1秒）内维护一个计数器，每来一个请求计数器加1，超过阈值则拒绝。窗口结束后计数器归零。

缺点
存在“窗口边缘突刺”问题。假设限制每秒10个请求，如果在第1秒的最后10毫秒内来了10个请求，第2秒的开始10毫秒又来了10个请求，那么在这20毫秒内实际有20个请求通过了，但系统没有检测到超限。对于反爬系统来说，这种突刺极易触发限流。因此，固定窗口计数器不推荐在生产环境中使用。

三、漏桶算法：平滑流量，保护后端

原理
漏桶算法将请求看作水流，桶底部有一个固定的漏水速率（即处理速率）。请求先进入桶中，以恒定速率流出并被处理。如果桶满了，新请求被丢弃或排队。

特点
• 输出速率恒定，无论输入流量如何波动，下游看到的都是平稳的请求流。
• 适合保护后端服务器或代理IP池，避免突发流量冲垮资源。
• 缺点是无法应对突发流量——即使你有能力处理，漏桶也会强制限速。

Python实现示例
import time
import threading

class LeakyBucket:
    def __init__(self, capacity, leak_rate):
        self.capacity = capacity
        self.leak_rate = leak_rate
        self.water = 0
        self.lock = threading.Lock()
    def allow_request(self):
        with self.lock:
            # 模拟漏水
            self.water = max(0, self.water - self.leak_rate)
            if self.water < self.capacity:
                self.water += 1
                return True
            return False
（实际使用时需要在循环中定期调用漏水逻辑，通常用后台线程实现）

四、令牌桶算法：允许突发，更灵活

原理
令牌桶以恒定速率向桶中添加令牌。每个请求需要消耗一个令牌才能被处理。如果桶中有足够的令牌，请求可以立即被处理；如果没有令牌，请求等待或被拒绝。桶的容量限制了最大突发流量。

特点
• 允许一定程度的突发：如果桶中有累积令牌，短时间内可以处理高于平均速率的请求。
• 平均速率受令牌添加速率限制，长期来看平滑。
• 更适合需要兼顾效率和稳定性的爬虫场景。

Python实现示例（基于时间戳）
import time
import threading

class TokenBucket:
    def __init__(self, capacity, fill_rate):
        self.capacity = capacity
        self.fill_rate = fill_rate
        self.tokens = capacity
        self.last_refill = time.time()
        self.lock = threading.Lock()
    def allow_request(self):
        with self.lock:
            now = time.time()
            elapsed = now - self.last_refill
            self.tokens = min(self.capacity, self.tokens + elapsed * self.fill_rate)
            self.last_refill = now
            if self.tokens >= 1:
                self.tokens -= 1
                return True
            return False

# 使用示例：桶容量10，每秒填充5个令牌（即平均QPS=5）
bucket = TokenBucket(10, 5)

五、代理IP场景中的限流策略设计

在实际的代理IP采集系统中，限流需要考虑多个维度，通常采用多级限流架构：

第一级：全局限流（控制整体QPS）
使用令牌桶限制所有Worker的总请求速率。例如，目标网站允许每秒最多100次请求，设置全局限流为每秒90次，留出余量。

第二级：单IP限流（每个代理IP的请求频率）
为每个代理IP分配独立的令牌桶。如果某个IP的请求频率过高（如超过每分钟30次），临时降低该IP的权重或切换到其他IP。这样可以避免单个IP过早被封。

第三级：动态限流（自适应反馈）
监控返回的状态码和响应时间。当检测到大量429或响应时间显著增加时，动态降低全局限流阈值；当恢复正常后逐步恢复。这种“反馈式限流”可以有效应对目标网站的压力变化。

六、分布式环境下的限流实现

当爬虫部署在多台机器上时，本地令牌桶无法做到全局限流（每台机器独立计数）。需要使用中心化限流方案：

基于Redis的分布式令牌桶
使用Redis存储令牌桶的状态（token数量、上次更新时间）。利用Lua脚本保证原子性操作。开源的Redis限流库如`redis-cell`模块提供了CL.THROTTLE命令，可以直接使用。或者自行实现：每个Worker在请求前向Redis申请令牌，使用Lua脚本消耗令牌并返回是否成功。

滑动窗口计数（更精确的分布式限流）
使用Redis的有序集合（Sorted Set）存储时间戳，统计当前时间窗口内的请求数量。这种方法比令牌桶更精确，但性能开销较大，适合对限流精度要求极高的场景。

七、常见限流陷阱与最佳实践

陷阱1：限流阈值设置过严
限流过严会导致采集速度远低于代理IP和网络的实际承载能力，浪费资源。建议通过灰度测试逐步提高阈值，找到性能拐点。

陷阱2：忽略响应时间波动
仅按请求数限流而不考虑响应时间，可能在目标网站响应变慢时仍然高速发送请求，导致超时和失败率上升。应将限流与熔断结合，当平均响应时间超过阈值时主动降低速率。

陷阱3：单IP限流与全局限流相互冲突
例如全局限流允许每秒100次，但每个IP限流允许每秒2次。如果有50个IP，两者是匹配的；如果只有10个IP，全局限流会远高于单IP的承载总和，导致单IP过载。正确的做法是取两者的最小值。

最佳实践清单
• 使用令牌桶算法，允许少量突发，模拟人类用户的访问特征。
• 在代码中集成自适应限流：根据返回的HTTP状态码动态调整阈值。
• 为代理IP池中的每个IP建立独立的请求计数器或令牌桶，避免单个IP过载。
• 在分布式系统中使用Redis实现中心化限流，保证多Worker协同。
• 设置合理的超时和重试，避免因限流排队导致的请求堆积。