限流与节流有何区别：n8n 详解工作流的退避策略

Hero：布局和类与首页 hero 相同（main.css）

文章内容

一连串 429（Too Many Requests）错误可能让原本健康的工作流陷入停滞。重试是解决方案的一部分，但时机很关键：重试太快，你很可能会再次撞上同样的限制。

理解节流与限流的区别，有助于你更明智地应对，从提前控制 API 调用节奏，到在服务商要求你等待时进行退避。

API 节流与限流：谁执行限制，谁负责适应

限流和节流都控制到达 API 的流量大小，但它们处理超额请求的方式并不相同。限流会设定客户端在给定时间段内可发起的请求数量上限。一旦超过该上限，服务商就可以拒绝额外请求，通常返回 429 Too Many Requests 响应。

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

该图说明了 API 限流与节流之间的区别：在第一种情况下，额外的 API 请求会导致错误，而在第二种情况下，它只是需要更长时间来处理

什么是 API 节流？

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

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

限流与节流：实际区别

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

滚动查看更多 ➔

限流 节流

超过限制时会发生什么？ 请求可能被拒绝 请求可能被延迟或排队

你的工作流会看到什么？ 一个错误（通常是错误 429） 更慢的响应

谁控制它？ API 服务商 API 服务商

你的工作流应该做什么？ 退避并重试 考虑增加的延迟

限流如何工作

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

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

固定窗口与滑动窗口

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

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

令牌桶与漏桶

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

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

不要假设每个 API 都奖励相同的请求模式。在决定以多激进的力度批量或调整调用节奏之前，请查看服务商的限流文档。

429（Too Many Requests）错误告诉你什么

当 API 因你超过其限流而拒绝请求时，HTTP 状态 429（Too Many Requests）会告诉你发生了什么。响应中可能还包含 Retry-After 头，指示客户端在再次发起请求前应等待多久。

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

指数退避

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

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

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

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

不带抖动的指数退避仍会导致峰值，而额外的随机延迟可以平滑负载。改编自：https://aws.amazon.com/blogs/architecture/exponential-backoff-and-jitter/💡当你使用使用工具的 AI 智能体系统时，加入抖动尤为重要。阅读我们关于 LLM 工具调用错误处理的文章，其中我们解释了何时可以重试，以及何时最好升级错误。

n8n 中的限流与退避模式

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

在 n8n 中，你可以在多个位置添加请求延迟。Loop 节点会分批处理传入项。在循环内部，你还可以添加一个 HTTP Request 节点，使用更小的批次和单独的延迟。

无需从头构建重试逻辑即可处理 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

与我们分享

其他助你上手的指南

有志者，工作流已在