规则:每秒 20 次请求
每个 API 密钥最多 每秒 20 次请求。这是唯一的速率限制。没有端点级限制、15 分钟窗口、每小时重置,也没有套餐之间的差异。 使用同一密钥的所有工作进程都需要协调总请求速率。即使已在本地控制请求节奏,也应处理429 响应。
需要了解的细节:
- 限制按 API 密钥计算,而非 IP 地址。多个密钥各有独立的每秒 20 次额度。
- 所有请求等量计数。 一次
/info调用和一次获取 100 条推文的/tweet-info-bulk调用,都算一次请求。 - 这不是滑动窗口。 计数每秒重置。在
T+0.00发送 20 次请求后,可在T+1.00再发送 20 次。
超过限制会怎样?
如果一秒内发送超过 20 次请求,超出的请求会返回429 Too Many Requests。不会丢失数据,也不会处罚密钥。等到下一秒后重试即可。
响应不包含 x-ratelimit-remaining 或 x-ratelimit-reset 请求头。由于限制每秒重置,在响应头中追踪剩余额度会增加复杂度,而实际价值有限。
如何避免超限
大多数工作负载在正常运行时不会接近每秒 20 次。如果运行批量任务或处理大型数据集,可以采用以下两种简单方式。方案 1:请求之间使用固定延迟
在单个串行工作进程中,每次收到响应后至少暂停 50ms,可限制发送速度。为了留出余量,可使用更长的暂停时间。多个进程共享密钥时,应使用统一的限流器;各自独立休眠 50ms 无法保证总速率不超过每秒 20 次。 Python方案 2:收到 429 后重试
如果希望全速运行并在触及限制后处理,可以捕获429 响应,短暂暂停后重试。
Python
429,再用重试逻辑兜底。
批量端点降低高吞吐需求
优化速度之前,先检查批量端点能否减少总请求次数:/info-batch:一次最多获取 100 份用户资料/tweet-info-bulk:一次最多获取 100 条推文