如何优雅处理API限流与设计高效重试策略

1. 为什么你的Agent总被限流？

最近在调试一个自动化Agent时，我遇到了一个令人头疼的问题——频繁收到429（Too Many Requests）状态码。这就像在社交场合中，如果你说话太快、太频繁，别人就会觉得你太聒噪而拒绝继续交流。服务器也是如此，当你的请求频率超过其承受范围时，它就会礼貌地（或不那么礼貌地）告诉你："慢一点，我受不了了"。

HTTP 429错误是服务器对客户端请求频率过高的响应。几乎所有主流API（如Twitter、GitHub、Stripe等）都会设置请求速率限制（Rate Limit）。以GitHub API为例，未认证用户每小时只能发起60次请求，而认证用户则可提高到5000次。超过这个限制，你就会收到429错误。

注意：不同API的限流策略差异很大。有些是按分钟/小时计数，有些采用滑动窗口算法，还有些会结合IP、账号等多维度限流。在编写重试逻辑前，必须仔细阅读目标API的限流文档。

2. 设计优雅的重试策略

2.1 基础重试机制

最简单的重试逻辑就是"遇到429就等待几秒再试"。但这样粗暴的等待往往效率低下。更聪明的做法是：

1. 解析响应头中的限流信息（如Retry-After）
2. 实现指数退避（Exponential Backoff）算法
3. 结合随机抖动（Jitter）避免请求同步

python复制import random
import time

def exponential_backoff(retry_count, base_delay=1, max_delay=60):
    """指数退避算法"""
    delay = min(base_delay * (2 ** retry_count), max_delay)
    return delay + random.uniform(0, delay * 0.1)  # 添加10%随机抖动

2.2 高级限流感知策略

真正的"社交高手"会预判对方的承受能力。我们可以：

1. 实时跟踪已用配额（通过X-RateLimit-Remaining等响应头）
2. 动态调整请求节奏
3. 实现漏桶或令牌桶算法

python复制class RateLimiter:
    def __init__(self, max_tokens, refill_rate):
        self.tokens = max_tokens
        self.max_tokens = max_tokens
        self.refill_rate = refill_rate  # tokens/second
        self.last_refill = time.time()

    def _refill(self):
        now = time.time()
        elapsed = now - self.last_refill
        self.tokens = min(
            self.tokens + elapsed * self.refill_rate,
            self.max_tokens
        )
        self.last_refill = now

    def acquire(self, tokens=1):
        self._refill()