Apigee - SpikeArrest 行为

Posted 2023-03-24

【中文标题】Apigee - SpikeArrest 行为

【英文标题】：Apigee - SpikeArrest behavior

【发布时间】：2014-03-21 15:53:39

【问题描述】：

我们正在使用一种秒杀政策，但我们不知道它是如何运作的。 秒杀配置如下：

<SpikeArrest enabled="true" continueOnError="true" async="false" name="SpikeArrest">
  <Rate>5pm</Rate>
  <MessageWeight ref="request.header.weight"/>
</SpikeArrest>

阅读文档，我们了解到，如果我们在一分钟内调用此流程超过 5 次，则该策略将在第 5 次之后的调用中失败。但是，当我们在 10 秒内使用 10 次调用对其进行测试时，该策略会接受前两次调用并在接下来的调用中失败。 你能解释一下为什么会这样吗？这是否与环境有 2 个消息处理器和 2 个路由器有关？

【参考方案1】：

尖峰逮捕不作为计数实施。它们目前被实施为基于成功处理最后匹配流量的时间的速率限制。

如果您指定每分钟 5 个，则意味着您的请求每 12 秒（1/5 分钟）只能收到一个。同一消息处理器上的第二个请求将在 12 秒内被拒绝。即使数量更大（每秒 100 个），如果两个请求几乎同时进入同一个消息处理器，一个也会被拒绝。每个成功（未逮捕）的请求都会更新尖峰逮捕的最后处理计数。

此外，每个消息处理器跟踪一个单独的时间。

如果您想要每分钟几十个范围内的值，您可能应该查看配额。

【讨论】：

感谢@MikeDunker 的回复。所以，根据我的配置，如果我连续发送 10 个请求，前两个将被处理，下一个调用不会，对吧？

不，只是时间问题。在给定的消息处理器上，如果现在收到请求，则所有后续请求都将失败，直到 12 秒过去。没有为尖峰逮捕保留计数器，只有最后一次流量成功通过尖峰逮捕政策的时间。

【参考方案2】：

Spike Arrest of 5 per minute 意味着它将允许每分钟最多 5 条消息，并在一分钟内平均分配这 5 条消息，即在一分钟的每 12 秒窗口中允许 1 条消息。现在，如果尖峰逮捕计数器没有在两个消息处理器之间同步，并且它是严格的循环，然后每个时间单位允许的消息值将加倍，在您的情况下，这可能是 12 秒内的 2 条消息，因此注意到的行为。

【参考方案3】：

将 Spike Arrest 视为一种通常防止流量高峰的方法，而不是将流量限制为特定数量的请求的方法。您的 API 和后端可以处理一定量的流量，而 Spike Arrest 策略可帮助您将流量平滑到所需的一般量。

运行时 Spike Arrest 行为与您输入的每分钟或每秒字面值可能期望看到的不同。

例如，假设您输入的速率为晚上 30 点（每​​分钟 30 个请求）。在测试中，您可能认为您可以在 1 秒内发送 30 个请求，只要它们在一分钟内到达。但这不是策略强制执行设置的方式。如果您考虑一下，在某些环境中，1 秒内的 30 个请求可能会被视为一个小峰值。

那么实际发生了什么？为了防止类似尖峰的行为，Spike Arrest 通过将您的设置划分为更小的间隔来平滑允许的完整请求数量：

每分钟费率平滑成允许以秒为间隔的完整请求。 例如，下午 30 点会像这样平滑： 60 秒（1 分钟）/ 30pm = 2 秒间隔，或每 2 秒允许 1 个请求。 2 秒内的第二个请求将失败。此外，一分钟内的第 31 个请求将失败。

每秒速率平滑成允许以毫秒为间隔的完整请求。 例如，10ps 会像这样平滑： 1000 毫秒（1 秒）/10ps = 100 毫秒间隔，或每 100 毫秒允许 1 个请求。 100 毫秒内的第二个请求将失败。此外，一秒钟内的第 11 个请求将失败。

还有更多： 1 个请求 * 消息处理器的数量 Spike Arrest 不是分布式的，因此请求计数不会在消息处理器之间同步。对于多个消息处理器，尤其是具有循环配置的消息处理器，每个消息处理器都独立处理自己的 Spike Arrest 节流。使用一个消息处理器，晚上 30 点的速率可将流量平滑到每 2 秒 (60 / 30) 1 个请求。使用两个消息处理器（Edge 云的默认设置），该数字每 2 秒翻一番，达到 2 个请求。因此，将您计算的每个时间间隔的完整请求数乘以消息处理器的数量，即可得出您的总体逮捕率。