n8n 工作流如何区分限流与节流并设计退避策略

一连串 429（请求过多）错误可能会让原本运行正常的工作流陷入停顿。重试是解决方案的一部分，但时机很重要：重试得太快，很可能再次触发同一个限制。

了解节流与速率限制的区别，有助于你更智能地应对问题：既可以提前控制 API 调用的节奏，也可以在服务提供商要求等待时进行退避。

API 节流与速率限制：谁来执行，谁来适应

速率限制和节流都会控制到达 API 的流量，但它们处理超额请求的方式并不相同。速率限制规定客户端在给定时间段内可以发出的请求数量上限。一旦超过该上限，服务提供商就可以拒绝后续请求，通常会返回 429 请求过多 响应。

而节流可以在流量超过允许速率时减慢或延迟请求。无论哪种情况，限制都由服务提供商控制。作为 API 使用者，你可以控制工作流如何响应：尽可能控制请求节奏以避免触及限制，并在达到限制时进行退避。

什么是 API 节流？

API 节流通过减慢请求流量，而不是让所有请求同时通过，来调节请求流量。当需求过高时，请求可能会被延迟或排队，直到有可用容量。

这并不一定意味着仅仅因为 API 承受压力，你的工作流请求就会失败。但请求可能需要更长时间才能完成。你的工作流仍然需要考虑这种延迟，尤其是在后续步骤依赖响应的情况下。

速率限制与节流：实际区别

假设某个 API 每分钟允许 100 个请求，而你的工作流在该分钟结束前发送了第 101 个请求。采用速率限制时，该请求可能会因 429 错误而被拒绝，之后由你的工作流决定何时再次尝试。采用节流时，服务提供商可能会将第 101 个请求暂时放入队列，稍后再处理。

这种差异会改变工作流所看到的结果（错误还是延迟），但不会改变谁掌握控制权。API 服务提供商负责执行流量策略。你的任务是调整请求模式，使工作流能够继续运行，同时避免反复让服务不堪重负。

向下滚动查看更多 ➔

速率限制如何工作

速率限制听起来很简单——请求过多，API 就会告诉你停止。但究竟多少才算过多，取决于服务提供商如何衡量流量。有些 API 会统计固定时间段内的请求数量，而另一些 API 允许短时突发请求，只要总体请求速率保持在规定范围内即可。

对你的工作流而言，底层算法很重要，因为它会改变你控制请求节奏的方式。稳定连续的调用在某个 API 上可能运行良好，但在另一个 API 上却可能触及限制。而当你确实越过限制时，通常会遇到错误 429——这是提示你该放慢速度的第一个信号。

固定窗口与滑动窗口

固定窗口速率限制将时间划分为固定的时间区间。API 可能允许每分钟发出 100 个请求，然后在下一分钟开始时重置计数器。虽然这让规则更容易理解，但在两个窗口的交界处可能会允许突然的请求突发。

滑动窗口通过在持续移动的时间段内统计请求，避免了这种硬重置。它不再询问自计时器开始以来你发出了多少请求，而是统计过去 60 秒内发出的请求数。等待时钟滚动到下一分钟，可能不会立即恢复工作流的完整请求额度。

令牌桶与漏桶

令牌桶算法允许一定程度的突发。可以把 API 分配给你的额度想象成一个以稳定速率接收令牌的桶。每个请求消耗一个令牌，未使用的令牌可以累积，但不会超过桶的容量。如果积累了足够多的令牌，工作流就可以一次发送多个请求，而不会超过限制。

漏桶采取相反的方法。请求进入队列，并以受控速率离开。突发请求会被平滑成更加稳定的流量，而不是一次性消耗积累的容量。

不要假设每个 API 都会奖励相同的请求模式。在决定以多激进的方式批量发送请求或控制调用节奏之前，请查看提供商的速率限制文档。

429（请求过多）错误说明了什么

当 API 因你超出速率限制而拒绝请求时，HTTP 状态码 429（请求过多）会告诉你发生了什么。响应还可能包含 Retry-After 标头，指示客户端在发出下一次请求前应等待多长时间。

如果存在 Retry-After，请使用它，而不是猜测何时重试。如果不存在，你的工作流就需要自行制定后续尝试之间的间隔策略。这正是指数退避的用武之地：不要以相同的间隔（或立即）重试，而是逐步增加尝试之间的延迟。

指数退避

当 API 告诉你放慢速度时，立即重试相同的请求可能会再次造成问题。指数退避通过在每次失败尝试后增加等待时间来避免这种循环。例如，工作流不是每秒重试一次，而是可能等待 1 秒、然后 2 秒、4 秒、8 秒，以此类推。

设置最大延迟和重试次数上限，避免临时的 API 问题导致工作流无限重试。如果 API 提供了 Retry-After 值，请遵循该指示，而不要只依赖自己的计划。

还有一个问题。多个同时失败的工作流也可能同时重试。加入抖动，即在每次延迟中加入少量随机性，可以分散这些尝试，有助于防止再次出现流量高峰。

确保请求可以安全地重复执行。带有副作用的请求可能会意外执行两次操作，因此在自动重试之前，请确认 API 是否支持幂等性。

💡

当你使用工具处理 AI 智能体系统时，加入抖动尤其重要。请阅读我们关于LLM 工具调用错误处理的文章，其中我们解释了何时可以重试，以及何时最好升级处理错误。 

n8n 中的限流与退避模式

你不需要从头开始构建速率限制处理机制。n8n 是一个源代码可见、AI 原生的自动化平台，为工程团队提供了多种使用 AI 代理或代理式工作流来处理速率限制的方式。你可以在请求达到 API 限制之前减慢请求速度，在失败后重试，或将持续出现的错误路由到其他位置。

无需从头构建重试逻辑，即可处理 API 速率限制

批量处理请求、添加等待节点，并将持续出现的 429 错误路由到错误工作流——全部在同一画布上完成

免费注册

正确的模式取决于 API。你可以通过批量处理并错开请求来主动控制流量，在单次调用之间添加等待，或在 API 返回 429 时配置重试。并发控制还可以限制并行执行数量，避免多个工作流合计压垮同一个 API。首先控制请求节奏，然后在限制仍然造成阻碍时，将重试和错误处理作为保障措施。

通过批量处理和等待节点控制请求节奏

对于限制可预测的 API，预防通常优于恢复。HTTP Request 节点可以使用 Items per Batch 和 Batch Interval 分批处理项目，并在批次之间暂停。这让你能够控制一次发出的请求数量，以及 n8n 在发送下一批请求前等待多长时间。

你可以通过这个用于批量处理 HTTP 请求的工作流查看实际模式。当你需要更精细的控制时，可以将Loop Over Items 与Wait 节点结合使用，根据 API 的限制逐个控制请求节奏。

失败时使用退避重试

控制请求节奏可以降低触发限制的可能性，但无法避免每个 429 错误。对于这些情况，Retry On Fail 可以自动重试失败的节点，并配置 Wait Between Tries，避免立即再次发送相同请求。

对于更复杂的情况，例如逐渐增加尝试之间的延迟，你可以在工作流中构建更高级的重试逻辑。这样，你可以控制何时再次尝试，以及何时彻底停止重试。

通过错误工作流捕获持续出现的 429 错误

即使耗尽重试次数，有些请求仍然会失败。你可以将这些失败通过单独的错误工作流进行日志记录、发送提醒或执行其他恢复步骤，而不是任由它们消失在执行历史记录中。

借助 n8n，你可以使用Error Trigger 节点，在另一个工作流失败时运行专用工作流。这样，持续出现的 429 错误就能触发定义好的恢复路径，而不是简单地结束执行。

💡

这里还有另一篇关于如何利用 API 速率限制创建更可靠工作流的指南。

使用 n8n 掌控 API 速率限制

你无法控制 API 设置的限制，但可以控制工作流触发这些限制时的响应方式。借助 n8n，这种响应本身就成为工作流的一部分，而不再需要你自行构建和维护自定义重试代码。

使用 n8n 掌控 API 速率限制

将请求节奏控制、重试和错误路由直接构建到工作流中，而不是使用需要维护的自定义代码

免费试用 n8n Cloud