内容来源：https://blog.n8n.io/throttling-vs-rate-limiting/

内容总结：

API频遭429错误致工作流中断，专家建议合理重试与限流应对

近日，技术社区关注到API调用中频繁出现的429（请求过多）错误对工作流稳定性的影响。专家指出，当API返回429错误时，简单重试并非万能解决方案，重试时机至关重要——过快重试很可能再次触发同一限制。理解“节流”与“限流”的区别，有助于开发者更智能地应对：既可在前端控制API调用节奏，也可在服务商提示等待时主动退避。

限流与节流：谁制定规则，谁负责适配

限流和节流均用于控制到达API的流量，但处理超额请求的方式不同。限流为客户端在特定时间段内的请求数量设定上限，一旦超出，服务商通常会以429响应拒绝额外请求。节流则是在流量超过允许速率时放缓或延迟请求。无论哪种方式，限制均由API服务商掌控；作为API使用方，开发者掌控的是工作流的响应方式——尽可能调整请求节奏以避免触限，并在触限时主动退避。

所谓API节流，是指通过放缓请求流向来调节流量，而非一次性放行所有请求。当需求过高时，请求可能被延迟或排队，直至容量可用。这并不意味着工作流中的请求必然失败，但完成时间可能延长，工作流需为这种延迟做好准备，尤其是后续步骤依赖该响应时。

限流与节流的实际区别

假设某API允许每分钟100次请求，而工作流在该分钟内发出了第101次请求。在限流机制下，该请求可能被以429错误拒绝，由工作流自行决定何时重试；在节流机制下，服务商可能将第101次请求放入队列稍后处理。这一差异改变了工作流看到的结果（错误还是延迟），但控制权归属不变：API服务商执行流量策略，开发者的任务是调整请求模式，使工作流持续运转而不反复压垮服务。

限流机制如何运作

限流看似简单——请求过多，API便要求停止。但“过多”的判定取决于服务商的计量方式。部分API在固定时间段内计数，另一些则允许短时突发，只要整体请求速率不越界。对工作流而言，底层算法很重要，因为它改变了请求节奏的安排方式。对某一API有效的稳定调用流，在另一API上可能触限。一旦越线，通常遇到的就是429错误——这是需要放慢节奏的首要信号。

固定窗口与滑动窗口

固定窗口限流将时间划分为设定区间。例如API可能允许每分钟100次请求，下一分钟开始时计数器重置。规则虽易理解，但可能在两个窗口交界处出现突发流量。滑动窗口则通过持续移动的时间段计量请求，避免硬性重置。它考虑的是过去60秒内的请求数量，而非计时开始后的累计数量。等待时钟翻转未必能立即恢复工作流的全部请求配额。

令牌桶与漏桶

令牌桶算法给予一定的突发空间。可将API配额想象为一只以稳定速率补充令牌的桶，每次请求消耗一个令牌，未使用的令牌可累积至桶容量上限。若积累足够令牌，工作流可一次性发送多个请求而不超限。漏桶则相反：请求进入队列并以受控速率流出，突发流量被平滑为更稳定的流，而非一次性消耗累积容量。专家提醒，不要假设所有API都认可相同的请求模式，在决定批量或调用节奏前应查阅服务商的限流文档。

429错误传递的信息

当API因超出限流而拒绝请求时，HTTP状态码429表明发生了何种情况。响应中可能包含Retry-After头，指示客户端应等待多久再发起下一次请求。若存在该头信息，应直接采用而非自行猜测重试时机；若不存在，工作流需自备后续尝试的间隔策略，指数退避便是常用方案：逐步增加每次尝试之间的延迟，而非以相同间隔或立即重试。

指数退避

当API要求放慢时，立即重试同一请求可能重蹈覆辙。指数退避通过每次失败后增加等待时间来避免这一循环。例如，工作流可依次等待1秒、2秒、4秒、8秒，以此类推。应设定最大延迟和重试次数上限，避免临时性API问题导致工作流无限重试。若API提供Retry-After值，应遵循该指引而非仅依赖自身安排。此外，多个同时失败的工作流也可能同时重试，在每次延迟中加入少量随机抖动，可分散尝试时点，有助于防止再次出现流量高峰。同时需确认请求可安全重复：具有副作用的请求可能意外执行两次，自动重试前应检查API是否支持幂等性。

n8n中的节流与退避模式

开发者无需从零构建限流处理机制。n8n是一个源可用的AI原生自动化平台，为工程团队提供多种方式处理AI代理或代理工作流中的限流问题：可在请求触及API限制前放慢速度，在失败后重试，或将持续错误路由至其他处理路径。合适的模式取决于具体API。可通过批处理和间隔请求主动控制流量，在单次调用间加入等待，或在API返回429时配置重试。并发控制还可限制并行执行数量，避免多个工作流共同压垮同一API。专家建议优先调整请求节奏，再将重试和错误处理作为限流仍生效时的保障手段。

利用批处理和等待节点调整请求节奏

对于限流可预测的API，预防通常优于补救。HTTP Request节点可通过“每批项目数”和“批间隔”设置分批处理项目并在批次间暂停，从而控制一次发出的请求数量以及n8n发送下一批前的等待时长。需要更精细控制时，可将“循环处理项目”与“等待”节点结合，围绕API限制逐个调整请求节奏。

失败重试与退避

调整请求节奏可降低触限概率，但无法杜绝所有429错误。对此，“失败时重试”功能可自动重试失败节点，并配置“重试间隔”以避免立即重发同一请求。更复杂的情况，如逐次增加尝试间隔，可在工作流中构建更高级的重试逻辑，从而掌控何时重试、何时停止。

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

部分请求在耗尽重试次数后仍会失败。与其让这些失败淹没在执行历史中，可通过独立的错误工作流进行日志记录、告警或其他恢复步骤。在n8n中，可使用Error Trigger节点在另一工作流失败时运行专用工作流，使持续的429错误触发既定的恢复路径，而非直接终止执行。

专家表示，API设定的限制无法改变，但工作流在触限时的响应方式可以掌控。借助n8n，这种响应成为工作流本身的一部分，而非需要自行构建和维护的自定义重试代码。

中文翻译：

一阵429（请求过多）错误就可能让原本健康的工作流陷入停滞。重试是解决方案的一部分，但时机很关键：重试太快，你很可能会再次触发同样的限制。

理解限流与速率限制的区别，有助于你更智能地应对——从预先控制API调用节奏，到在服务提供商告知你需要等待时进行退避。

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

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

而限流则可以在流量超过允许速率时减慢或延迟请求。无论哪种方式，提供商控制着限制。作为API消费者，你控制的是工作流如何响应：尽可能调整请求节奏以避免触及限制，并在触及限制时进行退避。

什么是API限流？

API限流通过减慢请求流来调节请求流量，而不是一次性放行所有请求。当需求过高时，请求可能被延迟或排队，直到容量可用。

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

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

假设某个API允许每分钟100个请求，而你的工作流在这一分钟结束前发送了第101个请求。在速率限制下，该请求可能被拒绝并返回429错误，让你的工作流自行决定何时重试。在限流下，提供商可能将第101个请求放入队列稍后处理。

这一区别改变了你的工作流看到的结果（错误还是延迟），但并没有改变谁在掌控。API提供商执行流量策略。你的工作是调整请求模式，使工作流能够持续运转，而不会反复压垮服务。

速率限制如何运作

速率限制听起来很简单——发出太多请求，API就会告诉你停止。然而，什么算作“太多”取决于提供商如何衡量流量。有些API在固定时间段内计算请求数，而另一些则允许短时突发，只要你的整体请求速率保持在范围内。

对于你的工作流来说，底层算法很重要，因为它改变了他应该如何调整请求节奏。稳定的调用流可能对某个API运行良好，但在另一个API上就会触及限制。而当你确实越线时，你通常会遇到错误429——这是该放慢速度的第一个信号。

固定窗口与滑动窗口

固定窗口速率限制将时间划分为固定的间隔。某个API可能允许每分钟100个请求，然后在下一分钟开始时重置计数器。虽然这让规则易于理解，但它可能允许在两个窗口边界附近出现突然的突发。

滑动窗口通过在一个持续移动的时间段内衡量请求来避免这种硬重置。它不是问你自计时器启动以来发了多少请求，而是考虑你在过去60秒内发了多少请求。等待时钟翻篇可能不会立即恢复你工作流的完整请求配额。

令牌桶与漏桶

令牌桶算法给你一些突发的空间。把你的API配额想象成一个以稳定速率接收令牌的桶。每个请求消耗一个令牌，未使用的令牌可以累积到桶的容量上限。如果积累足够的令牌，你的工作流可以一次性发送多个请求而不超过限制。

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

不要假设每个API都奖励相同的请求模式。在决定批处理或调用节奏的激进程度之前，请查看提供商的速率限制文档。

429（请求过多）错误告诉你什么

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

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

指数退避

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

设置最大延迟和重试次数上限，这样暂时的API问题不会让你的工作流无限重试。如果API提供了Retry-After值，请遵循该指引，而不是仅依赖你自己的时间安排。

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

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

n8n中的限流与退避模式

你不需要从零构建速率限制处理。n8n是一个源可用的、AI原生的自动化平台，为工程团队提供了多种方式来处理AI代理或代理式工作流中的速率限制。你可以在请求触及API限制之前放慢速度，在失败后重试，或将持续错误路由到其他地方。

正确的模式取决于API。你可以批处理并间隔请求来主动控制流量，在单个调用之间添加等待，或在API返回429时配置重试。并发控制还可以限制并行执行数量，使多个工作流不会共同压垮同一个API。先调整请求节奏，然后在限制仍然阻碍时使用重试和错误处理作为保障。

通过批处理和等待节点调整请求节奏

对于限制可预测的API，预防通常优于恢复。HTTP Request节点可以通过“每批项目数”和“批次间隔”来分批处理项目并在批次之间暂停。这让你控制一次发出多少请求以及n8n在发送下一批之前等待多长时间。

你可以通过这个批处理HTTP请求的工作流看到实际应用中的模式。当你需要更精细的控制时，将“循环项目”与“等待”节点结合使用，围绕API限制逐个调整请求节奏。

失败时退避重试

调整请求节奏降低了触及限制的机会，但无法预防每一个429。对于这些情况，“失败时重试”让你自动重试失败的节点，并配置“重试间隔”以避免立即发送相同的请求。

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

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

有些请求在你耗尽重试次数后仍然会失败。与其让这些失败消失在执行历史中，你可以将它们路由到单独的错误工作流进行日志记录、告警或其他恢复步骤。

使用n8n，你可以使用Error Trigger节点在另一个工作流失败时运行一个专用工作流。这样，持续的429错误可以触发一条已定义的恢复路径，而不仅仅是结束执行。

使用n8n掌控API速率限制

你无法控制API设定的限制，但你可以控制工作流在触及限制时的响应方式。使用n8n，这种响应成为工作流本身的一部分，而不是你必须构建和维护的自定义重试代码。

英文来源：

A burst of 429 (Too Many Requests) errors can bring an otherwise healthy workflow to a halt. Retrying is part of the solution, but timing matters: Retry too quickly and you’re likely to hit the same limit again.
Understanding throttling versus rate limiting helps you respond more intelligently, from pacing API calls upfront to backing off when the provider tells you to wait.
API throttling vs. rate limiting: Who enforces, who adapts
Rate limiting and throttling both control how much traffic reaches an API, but they don’t handle excess requests the same way. A rate limit sets a cap on how many requests a client can make within a given period. Once you cross that cap, the provider can reject additional requests, often with a 429 Too Many Requests response.
Throttling can instead slow or delay requests when traffic exceeds an allowed rate. Either way, the provider controls the limit. As the API consumer, you control how your workflow responds: pacing requests to avoid the limit where possible and backing off when you hit it.
What Is API throttling?
API throttling regulates request traffic by slowing its flow instead of just letting every request through at once. When demand gets too high, requests may be delayed or queued until capacity becomes available.
That doesn’t necessarily mean a request for your workflow fails just because the API is under pressure. But it can take longer to complete. Your workflow still needs to account for that delay, especially when later steps depend on the response.
Rate limiting vs. throttling: The practical difference
Imagine an API allows 100 requests per minute and your workflow sends request 101 before that minute is up. With rate limiting, that request may be rejected with a 429 error, leaving your workflow to decide when to try again. With throttling, the provider may hold request 101 in a queue and process it later instead.
That difference changes what your workflow sees (an error versus a delay) but not who’s in control. The API provider enforces the traffic policy. Your job is to adapt your request pattern so the workflow can keep moving without repeatedly overwhelming the service.
How rate limits work
Rate limits sound simple — make too many requests, and the API tells you to stop. What counts as too many, though, depends on how the provider measures traffic. Some APIs count requests within a fixed period, while others allow short bursts as long as your overall request rate stays within bounds.
For your workflow, the underlying algorithm matters because it changes how you should pace requests. A steady stream of calls might work well against one API but run into limits with another. And when you do cross the line, you’ll often encounter Error 429 — your first clue that it’s time to slow down.
Fixed vs. sliding windows
A fixed-window rate limit divides time into set intervals. An API might allow 100 requests every minute, then reset the counter when the next minute begins. While this makes the rule easy to understand, it can allow sudden bursts around the boundary between two windows.
A sliding window avoids that hard reset by measuring requests over a continuously moving period. Instead of asking how many requests you’ve made since the timer began, it considers how many you’ve made over the previous 60 seconds. Waiting for the clock to roll over may not immediately restore your workflow’s full request allowance.
Token buckets vs. leaky buckets
Token bucket algorithms give you some room to burst. Think of your API allowance as a bucket that receives tokens at a steady rate. Each request spends a token, and unused tokens can accumulate up to the bucket’s capacity. If enough tokens have built up, your workflow can send several requests at once without exceeding the limit.
A leaky bucket takes the opposite approach. Requests enter a queue and leave at a controlled rate. Bursts get smoothed into a steadier flow instead of consuming accumulated capacity all at once.
Don’t assume every API rewards the same request pattern. Check the provider’s rate-limit documentation before deciding how aggressively to batch or pace calls.
What a 429 (Too Many Requests) error tells you
When an API rejects a request because you’ve exceeded its rate limit, HTTP status 429 (Too Many Requests) tells you what happened. The response may also include a Retry-After header indicating how long the client should wait before making another request.
If Retry-After is present, use it instead of guessing when to retry. If it’s not, your workflow needs its own strategy for spacing subsequent attempts. That’s where exponential backoff comes in: Instead of retrying at the same interval (or immediately), you progressively increase the delay between attempts.
Exponential backoff
When an API tells you to slow down, immediately retrying the same request can recreate the problem. Exponential backoff avoids that loop by increasing the wait after each failed attempt. Instead of retrying every second, for example, your workflow might wait one second, then two, four, eight, and so on.
Set a maximum delay and retry limit so temporary API issues don’t leave your workflow retrying indefinitely. If the API provides a Retry-After value, respect that guidance rather than relying solely on your own schedule.
There’s another wrinkle. Multiple workflows that fail together can also retry together. Adding jitter, or a small amount of randomness to each delay, spreads those attempts out and helps prevent another traffic spike.
Make sure the request is safe to repeat. Requests with side effects can accidentally perform an action twice, so check whether the API supports idempotency before automatically retrying them.
Throttling and backoff patterns in n8n
You don’t need to build rate-limit handling from scratch. n8n is a source-available, AI-native automation platform that gives engineering several ways to handle rate limits with AI agents or agentic workflows. You can slow requests before they hit the API limit, retry after a failure, or route persistent errors elsewhere.
The right pattern depends on the API. You can batch and space requests to control traffic proactively, add waits between individual calls, or configure retries when an API responds with a 429. Concurrency controls can also cap parallel executions so multiple workflows don’t collectively overwhelm the same API. Pace requests first, then use retries and error handling as safeguards when limits still get in the way.
Pace requests with batching and wait nodes
For APIs with predictable limits, prevention is usually better than recovery. The HTTP Request node can process items in batches and pause between them using Items per Batch and Batch Interval. This lets you control how many requests go out at once and how long n8n waits before sending the next batch.
You can see the pattern in practice with this workflow for batching HTTP requests. When you need finer control, combine Loop Over Items with a Wait node to pace requests individually around the API’s limits.
Retry on fail with backoff
Pacing requests reduces the chance of hitting a limit, but it can’t prevent every 429. For those cases, Retry On Fail lets you automatically retry a failed node and configure the Wait Between Tries so you don’t immediately send the same request again.
For more complex cases, like increasing the delay between attempts, you can build more advanced retry logic into the workflow. This gives you control over when to try again and when to stop retrying altogether.
Catch persistent 429s with error workflows
Some requests will still fail after you’ve exhausted your retries. Instead of letting those failures disappear into the execution history, you can route them through a separate error workflow for logging, alerts, or other recovery steps.
With n8n, you can use the Error Trigger node to run a dedicated workflow when another workflow fails. That way, persistent 429 errors can trigger a defined recovery path instead of just ending the execution.
Take control of API rate limits with n8n
You can’t control the limits an API sets, but you can control how your workflow responds when it hits them. With n8n, that response becomes part of the workflow itself instead of custom retry code you have to build and maintain.