Apigee - SpikeArrest行为

Question

我们正在使用一种峰值修复策略，但我们不了解它是如何工作的。尖峰截获配置如下：

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

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

Answer 1

尖峰逮捕不是作为计数来实现的。它们当前被实现为基于成功处理最后匹配业务的时间的速率限制。

如果您指定每分钟5个，则意味着您的请求每12秒(1/5分钟)只能有一个请求。同一消息处理器上12秒内的第二个请求将被拒绝。即使有一个更大的数字(每秒100个)，如果两个请求几乎同时进入同一个消息处理器，其中一个将被拒绝。每个成功的(未被捕获的)请求都将更新尖峰捕获的最后处理计数。

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

如果您希望值在每分钟十位的范围内，您可能应该查看配额。

Answer 2

每分钟5条尖峰阻止意味着它将允许每分钟最多5条消息，并在一分钟内均匀分布这5条消息，即在minute.Now的每12秒窗口中允许1条消息。如果尖峰阻止计数器没有在两个消息处理器之间同步，并且它是严格的循环，那么每个时间单位允许的消息值将翻一番，在您的情况下可能在12秒内有2条消息，因此出现了注意到的行为。

Answer 3

可以将尖峰捕获看作是防止流量峰值的一种方式，而不是将流量限制在特定数量的请求的一种方式。您的API和后台可以处理一定的流量，尖峰拦截策略可以帮助您将流量平滑到您想要的一般流量。

运行时尖峰停止行为与您输入的每分钟或每秒的文字值所期望看到的不同。

例如，假设您输入的速率为30 per (每分钟30个请求)。在测试中，您可能认为您可以在1秒内发送30个请求，只要它们在一分钟之内。但这并不是策略强制执行设置的方式。如果你仔细想想，在某些环境中，1秒内的30个请求可能被认为是一个小峰值。

那么，实际发生了什么呢？为了防止尖峰行为，尖峰捕获通过将您的设置划分为较小的间隔来平滑允许的完整请求数：

每分钟速率被平滑为允许的以秒为间隔的完整请求。例如，30 or可以像这样平滑: 60秒(1分钟)/30 or=2秒间隔，或者每2秒允许1个请求。2秒内的第二次请求将失败。此外，一分钟内的第31个请求将失败。

每秒的速率平滑为允许的以毫秒为间隔的完整请求。例如，10ps是这样平滑的: 1000毫秒(1秒)/ 10ps = 100毫秒间隔，或者每100毫秒允许1个请求。在100ms内的第二个请求将失败。此外，一秒钟内的第11个请求将失败。

还有更多：1请求*消息处理器的数量尖峰抑制不是分布式的，因此请求计数不会在消息处理器之间同步。使用多个消息处理器，特别是那些具有循环配置的消息处理器，每个处理器都独立地处理自己的尖峰截获节流。使用一个消息处理器，30 30的速率将流量平滑到每2秒1个请求(60 / 30)。使用两个消息处理器( Edge cloud的默认设置)，这个数字会翻一番，达到每2秒2个请求。因此，将您计算出的每个间隔的完整请求数乘以消息处理器的数量，就可以得到您的总体拦截率。