Leadde Logo

了解 API 速率限制

精炼课程,深入剖析 API 速率限制的原理、实施原因、常见重试误区,以及指数退避等高效模式。
L作者 Leadde 更新于 2026年8月22日

速率限制如何决定您的请求能否成功运行

速率限制规定了客户端在特定时间窗口内可发送的请求数量,一旦超出上限,将返回 429 错误。此限制旨在防止单个客户端占用所有共享资源,因此正确的应对方式是放慢速度,而非立即重试。

然而,大多数首次集成都会选择立即重试,这会将暂时的拒绝转变为持续的阻塞。客户端触及限制后,立即重试,反而延长了被测量的时间窗口,导致被限流的时间远超最初的突发请求所需,通常会让开发者误以为 API 不稳定。我们有意不在此处讨论您自己的限制配置:例如分级阈值、突发流量配额以及更严格的端点限制,这些内容更适合放在版本化文档中,而非易过时的视频教程里。

此模板通过八个场景追踪一个请求:一个场景解释限制为何存在,一个解释时间窗口及其计数方式,一个解释 429 响应包含什么,两个解释退避机制及延迟为何必须增长,一个解释抖动和“惊群效应”,一个解释如何读取速率限制头,以及一个解释如何设计以避免频繁触及限制。

两分钟内掌握退避机制

开发者教育需要与用户已打开的文档竞争。任何重复参考页面的内容都会在二十秒内被关闭,因此本模块必须专注于文档难以清晰传达的关键点:即故障模式,而非仅仅参数。

先展示重试风暴,再给出解决方案

先展示重试风暴,再给出解决方案

客户端在已超出限制后仍每 200 毫秒重试一次,这正是问题的症结所在,在一个场景中即可清晰展现。退避机制因此成为显而易见的解决方案,而非仅仅一项建议。

明确展示倍增效果

一秒、两秒、四秒、八秒。直接展示这种递进关系比定义指数退避更快捷,也更贴近开发者实际的实现方式。

突出抖动机制的重要性

如果没有随机化处理,所有被限流的客户端会同时重试,导致恢复尝试演变为下一次服务中断。这是大多数集成方案容易忽略的关键点,也是本模块存在的意义。

指导读取响应头,而非死记数字

限制会变,但报告这些限制的响应头不会。教会客户端读取这些信息,远胜于硬编码一个下个季度就会失效的阈值。

从您已发布的 API 文档中提取内容

上传您的 API 文档、发送给合作伙伴的集成指南,或上次入职培训的支持工单——最大 200 MB,支持 PDF、DOC、DOCX、PPTX 或 TXT 格式。生成的场景可供编辑,原始文档保持不变。

与您的 API 保持一致

在屏幕上使用您自己的响应头名称

在屏幕上使用您自己的响应头名称

不同平台间的响应头命名各异,向开发者展示通用示例后,他们仍需自行查找您的具体名称。在场景中直接使用真实名称,可省去这一步骤。

明确说明反复违规后的处理方式

明确说明反复违规后的处理方式

有些平台会限流,有些会暂停密钥,有些则会通知人工介入。明确说明后果,能让合作伙伴更认真地对待指导。

精心设计字幕样式,确保术语准确无误

精心设计字幕样式,确保术语准确无误

状态码、响应头名称和参数值容易听错,但阅读则能确保准确无误。从九种字幕样式中选择,在整个开发者系列中保持一致,并确保代码术语在小尺寸下依然清晰可辨。

API 速率限制常见问题

速率限制控制短时间窗口(通常为几秒或一分钟)内的请求速度,通过等待即可恢复。而配额则管理计费周期内的总使用量,无法通过等待恢复。混淆两者会导致客户端在需要申请增加配额时却错误地执行退避操作。

如果提供了 `retry-after` 值,请读取该值,至少等待相应时长,然后以每次后续失败都递增的延迟进行重试。立即重试或以固定短间隔重试只会延长限流时间,而非解除限流。

端点名称可以,这能让模块更有用。但密钥和令牌不行,即使是已过期的也不可以,因为培训视频会在其目标合作伙伴之外传播,并且其生命周期远长于凭证本身。

因为在大多数实现中,失败的请求仍然会计入时间窗口。每次重试都会让客户端进一步超出限制,因此,每次试图避免等待的尝试,都会导致解除限流所需的等待时间更长。

在生产环境限流前,先做好准备

将您已发布的 API 文档导入其中,然后在下一次合作伙伴集成前,优化完善这些场景。

avatar

从这个模板开始,快速得到可分享的视频。

添加你的入门指南或帮助中心页面,几分钟内生成可编辑的初稿。