什么是速率限制?

组织使用速率限制来确保客户公平使用其基于 API 的服务以及其他 Web 服务和资源。它规定了用户在给定时间范围内可以请求基于 API 的特定服务的次数。

速率限制图

当成千上万的用户共享一项服务时,速率限制有助于所有客户都可使用系统。速率限制还可以保护系统免受拒绝服务攻击 (DoS) 。在 DoS 攻击中,恶意用户可能会在短时间内发起大量服务请求。这导致资源的耗尽,也就意味着合法用户无法使用该系统。在某些情况下,由于客户端或用户端的错误,Web 服务、API 或其他资源可能会收到大量请求。速率限制是组织用来避免出现此类情况的切实有效的方法。

社交媒体消息传递的限制是大多数互联网用户遇到的速率限制典型实例。Facebook、LinkedIn 或 Instagram 等社交媒体网站通常会限制用户每天可以发送的直接消息数量。例如,如果用户决定将消息转发给成千上万的联系人,那么社交媒体服务的速率限制逻辑就会启动。它可能会阻止用户在一段时间内再发送任何消息。

为什么组织需要速率限制?

在数字时代,组织通过 API 提供大部分服务。这些基于 API 的服务使组织能够很好地控制自己的系统。但是,托管这些 API 和后端数据库会给他们的资源带来负担。组织应使用速率限制来确保其 API 的合理使用,防止某些用户耗尽其资源。如果 API 使用很普遍,用户数量会迅速激增。在这种情况下,组织需要确保其所有服务都可用且不会超负荷。速率限制还有助于组织保护、管理其服务并从中获利。

速率限制成功指南
API 产品经理的权威成功指南
通过 7 部分成功指南了解公司如何创建 API 程序以发展数字业务,充分发挥 API 的强大性能!

速率限制的主要类型有哪些?

根据企业提供的 Web 服务的性质,企业可以在几种主要的速率限制类型之间进行选择,具体取决于哪种模型最适合企业,我们将在下面详细探讨。

用户级速率限制

如果系统可以唯一标识用户,就可以限制用户在一段时间内发出的 API 请求的数量。例如,如果用户每秒只能发出两个请求,则系统会拒绝用户在同一秒内发出的第三个请求。用户级别的速率限制可确保公平使用。但是,维护每个用户使用的统计信息可能会给系统带来开销,如果并非出于其他原因,这可能会消耗资源。

服务器级速率限制

大多数基于 API 的服务本质上都是分布式的。这意味着当用户发送请求时,它可能由众多服务器中的一台提供服务。在分布式系统中,速率限制可用于服务器之间的负载共享。例如,如果一台服务器在分布式系统中收到十台服务器发出的大量请求,而其他服务器大部分处于空闲状态,则该系统没有得到充分利用。在服务器级别速率限制中,特定服务器可以处理的服务请求数量将受到限制。如果服务器收到的请求超过了此设定限制,则这些请求将被丢弃或路由到另一台服务器。服务器级速率限制可确保系统的可用性,并防止针对特定服务器的拒绝服务攻击。

基于地理位置的速率限制

大多数基于 API 的服务都使用遍布全球的服务器。当用户发出 API 请求时,靠近用户地理位置的服务器将完成该请求。组织实施基于地理位置的速率限制,以限制来自特定地理区域的服务请求数量。这也可以根据时间设定来完成。例如,如果从凌晨 1:00 到早上 6:00 之间来自特定地理位置的请求数量很少,那么 Web 服务器可以在此特定时间段内设置速率限制规则。如果在这段时间内服务器受到攻击,请求数量将激增。如果出现峰值,速率限制机制将触发警报,组织可以快速响应此类攻击。

速率限制使用哪些算法?

固定窗口速率限制

固定窗口速率限制在特定时间限制 API 请求的数量。例如,服务器可以使用一个速率限制组件,实现每分钟只能接受 100 个请求的固定窗口算法。时间范围是固定的,从特定时间开始。例如,服务器在上午 10:00 至上午 10:01 之间仅处理 100 个请求。在上午 10:01 时,窗口重置。固定窗口算法可以在用户级别或服务器级别实现。如果是在用户级别实现的,则每个用户每分钟可以发出 100 个请求。如果是服务器级别,那么所有用户每分钟总共可以发出 100 个请求。

下图显示了具有用户级速率限制的固定窗口算法的工作流程。在此工作流中,为用户分配一个用于唯一标识的密钥,并且每个唯一用户都会有一个计数器,当用户在某个时间范围内发出请求时,计数器会递增。

固定窗口算法的优缺点

固定窗口算法易于实现,因为它基于固定的时间范围。由于请求计数在每个时间范围的开始时都会更新,因此固定窗口算法不会出现新请求不足的情况。另一方面,固定窗口算法的一个缺点是导致请求激增,尤其是在时间窗口开始时。例如,如果服务器每秒允许 1000 个请求,则所有这 1000 个请求都可能同时发生,可能使服务器超载。之所以会出现此问题,是因为两个请求之间的最小时间间隔没有限制。

漏桶速率限制

与固定窗口算法不同,漏桶算法与时间窗无关。相反,它有一个不依赖于时间的固定长度队列。Web 服务器以先到先得的原则为请求提供服务。每个新请求都会添加到队列的末尾。如果新请求到达时队列已满,则服务器将丢弃该请求。

漏桶算法的优缺点

漏桶算法的一个主要优点是,由于它基于队列,因此很容易实现。此外,它以恒定的速率向服务器提出 API 请求。与固定窗口算法不同,在任何特定时间都不会出现请求数量激增。但是,由于漏桶算法基于静态队列,因此存在请求不足的可能性,这意味着较新的请求可能根本无法得到服务。固定窗口中不存在此问题,因为时间窗口会定期刷新以接受新的请求。

滑动窗口速率限制算法

除了时间窗的起点外,滑动窗口算法与固定窗口算法非常相似。在滑动窗口中,只有在发出新请求时才会启动时间窗口。例如,如果第一个请求是在上午 10:02 发出的,并且服务器每分钟允许两个请求,则时间范围为上午 10:02 到 10:03。

滑动窗口算法有效地解决了固定窗口算法面临的突发请求问题。它还解决了漏桶算法面临的请求不足问题。

速率限制的主要用途是什么?

速率限制的主要目的是确保公平使用共享资源。除此之外,速率限制是一种多用途技术,组织可能会出于各种原因而使用。

速率限制提供额外的安全性

速率限制防止拒绝服务 (DoS) 攻击。在 DoS 攻击中,恶意用户发起大量服务请求以使系统崩溃。例如,如果音乐会发起人和门票销售网站在音乐会开始销售后每秒钟内收到一百万个请求,系统就会卡死,网络服务器和数据库也可能变得不可用。通过速率限制,网站可以阻止任何此类尝试。即使客户端没有任何不正当的意图,拒绝服务攻击甚至也可能会发生。当发出请求的系统(客户端)出现错误时,就会发生这种情况。速率限制还可以防止此类意外攻击。

访问控制

速率限制不仅涉及限制请求数量,还可以对其进行修改以限制访问级别。例如,如果有基于 API 的服务可以查看和修改用户的个人详细信息,则速率限制算法可以实现不同的访问级别。一组用户只能查看个人详细信息,而第二组用户可以查看和修改详细信息。

API 计量

在 API 业务模型中,速率限制可用于计量使用情况。例如,如果用户注册了每小时允许 1000 个 API 请求的套餐,则速率限制逻辑将限制任何超过上限的 API 请求。此外,速率限制算法可以动态地允许用户每秒购买更多请求。

保证性能

实现速率限制逻辑的一个关键目标是确保 API 的性能。当系统允许无限制的请求时,服务器的性能会降低并减慢 API 的运行速度。在极端情况下,服务器可能无法接受任何请求。这可能会导致分布式系统出现级联故障,即来自无法正常工作的服务器的负载被分配到其他服务器,并逐渐使它们过载。速率限制通过在用户级别或服务器级别限制请求来防止出现这种情况。

确保可用性

基于 API 的服务的主要要求之一是其全天候可用性。每秒钟都有成千上万的用户访问一个 API。即使停机几秒钟也可能给组织带来巨大损失。因此,力争实现零停机符合每个组织的最大利益。速率限制和其他技术(如负载共享)允许组织限制 API 请求的激增并确保系统的可用性。

客户端和服务器端的速率限制

服务器端速率限制

在服务器端限制用户请求是一种广泛使用的速率限制方法。限制不受限的用户请求以确保性能和可用性符合服务提供商的利益。正如我们在上一节中所看到的,组织出于各种目的使用服务器端速率限制。

客户端速率限制

速率限制看起来可能只迎合 API 提供商的利益。实际上,服务的用户或客户也可以从速率限制中受益。遵守使用限制的客户始终可以放心,服务提供商会满足他们的请求。如果用户没有考虑速率限制,那么他们可能不得不面对突然或意外的请求被拒,这可能会影响其解决方案的功能。

例如,移动应用程序可能是基于 Facebook 的消息传递 API 构建的。当人们使用此应用程序时,他们实际上是在后台使用 Facebook 消息传递。在这种情况下,客户端必须采取措施来确保应用程序遵守速率限制规范。如果客户端忽略了速率限制,则此移动应用程序的用户可能会遇到意外错误。在客户端实施速率限制符合 API 用户的最大利益。

速率限制软件
尝试 TIBCO Cloud Integration - 免费试用
让 TIBCO 云集成通过更方便快捷的 API 主导式集成为您的企业提供强劲支持。以集成方式实现简化。

实施速率限制有哪些挑战?

分布式系统

在具有分布式服务器的系统中实现速率限制逻辑是一项挑战。当用户从分布式系统请求基于 API 的服务时,每台服务器中的速率限制组件应彼此同步。例如,假设用户已经用完了每分钟五个请求配额中的四个,并且又发出了两个请求,那么这两个请求将发送到两个不同的服务器。每台服务器都会提取用户的请求计数,并认为该用户只发出了四个请求。然后两台服务器都允许服务请求。因此,用户每分钟收到六个请求,而不是原来的每分钟五个请求。在分布式系统中实施速率限制时,可能会出现许多此类同步问题和竞态条件。

对于分布式系统中的速率限制不一致问题,有多种解决方案。使用软件锁来保护用户请求计数器的服务器是一种解决方案。在此方法中,只有一台服务器将访问计数器,该计数器存储在时间窗内发出的请求数。另一个简单但不够灵活的解决方案是粘性会话,其中单个服务器始终为用户提供服务。但是,这不符合分布式系统的概念。

计算开销

为了限制速率而添加额外的逻辑层将增加服务器的计算开销。如果系统已经过载,添加速率限制逻辑将进一步降低系统的速度,并且用户可能会遇到延迟。

速率限制逻辑可以作为外部组件合并,不用在同一服务器中实现。每当用户请求 API 时,请求首先通过此外部组件进行路由,该外部组件决定允许还是拒绝该请求。

速率限制组件出现故障

为速率限制增加了一层额外的复杂性,增加了新的故障机会。即使 API 已启动并运行,速率限制组件中的错误也会导致请求被拒。

良好的速率限制实施应该能够快速从故障中恢复。这可以是发生故障时硬重置的形式。此外,就像基于 API 的服务中的备份服务器一样,可以使用重复的速率限制组件,在原始组件出现故障时承担起这个角色。