我们的组织目前正在迁移到Apigee。
我目前遇到的问题与此问题非常相似，但由于我是StackOverflow新手并且声誉很低，我无法对其发表评论：Apigee - SpikeArrest behavior
如果有任何方法可以合并这两个问题，请告诉我。
因此，在我们的组织中，我们有6个MessageProcessors（MP），我认为他们正在以严格的循环方式工作。
请参阅此配置（它适用于ApiProxy的TARGET ENDPOINT）：
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<SpikeArrest async="false" continueOnError="false" enabled="true" name="spikearrest-1">
<DisplayName>SpikeArrest-1</DisplayName>
<FaultRules/>
<Properties/>
<Identifier ref="request.header.some-header-name"/>
<MessageWeight ref="request.header.weight"/>
<Rate>3pm</Rate>
</SpikeArrest>
我有一个下午3点的速度，这意味着根据ApigeeDoc1计算每20秒一次。
问题是，不是每20秒成功命中一次，而是在20秒范围内获得6个成功命中，然后是SpikeArrest错误，这意味着它以循环方式击中每个MP一次。 < / p>
这意味着我的api后端每20秒获得6次命中，而不是每20秒获得所需的1次命中。
有没有办法在国会议员中同步穗状匪？
ConcurrentRatelimit似乎没有帮助......
非常感谢任何帮助或建议！
谢谢！
答案 0 :(得分：0)
与配额限制不同，Spike Arrest无法在MP之间同步。
但是，当您在每分钟级别设置它们时，您可以使用配额策略 - 然后将其设置为“分布式”和“同步”，它将在MP之间进行协调。
请记住，跨机器的同步总会有一些延迟，因此它永远不会是一个完全精确的数字。
答案 1 :(得分：0)
SpikeArrest无法跨消息处理器分发。它通常用于阻止大量流量突发，而不是控制您建议的流量（每分钟3次呼叫）。您通常将其放入代理请求预流程中，并在流量过高时中止。
使用SpikeArrest与您的循环消息处理器每分钟最接近3分钟，每分钟1次，这将导致每分钟6次呼叫。您只能将SpikeArrests指定为“每秒n个”或“每分钟n个”，如上所述，它会转换为“每1 / n秒1个”或“每1分钟1个”。
你真的只支持你的后端每20秒拨一个电话吗？如果您尝试每个用户或应用每20秒支持一次呼叫，那么我建议您尝试使用Quota policy来完成此操作。配额可以在所有消息处理器之间共享计数器。您还可以通过指定作为常量的配额标识符，对所有流量（而不是每个用户或每个应用）使用配额。你可以每分钟允许3次，但是他们可以在那一分钟内同时进入。
如果您只是想防止过度使用后端，则经常会使用ConcurrentRateLimit policy。
最后一个解决方案是实现一些自定义代码。
重申：
要获得您正在寻找的粒度，您需要使用配额。遗憾的是，您无法将配额设置为在分布式配额上具有“每秒”值（分布式配额在消息处理器之间共享计数，而不是让每个消息处理器都有自己的计数器）。你能做的最好的是每分钟，在你的情况下每分钟300次。否则，您可以使用非分布式配额（在6个消息处理器之间划分配额），但是您遇到的问题是，某些MP上的呼叫将被拒绝而其他MP将被接受，这可能会让人感到困惑。你的开发者。
对于分布式配额，您需要在API产品中设置每分钟300个电话（请参阅the docs），并将该产品分配给您的四个应用。然后，在您的代码中，如果没有为当前API调用的应用程序分配该产品，您将使用硬编码为每秒10（600每分钟）的配额并使用常量标识符而不是client_id，以便所有其他流量使用该配额。
配额不会阻止您几乎同时提交所有请求，我假设您的后端无法同时处理1200多个请求。您需要使用SpikeArrest策略来平滑流量。您需要允许后端可以处理的SpikeArrest的最大流量。这有助于防止流量高峰，但您可能会获得一些通常被配额允许的流量。应在配额之前检查SpikeArrest策略，以便拒绝流量不计入应用的配额。
正如您可能看到的那样，为像您这样的情况进行配置更像是一门艺术，而不是一门科学。我的建议是进行重要的性能/负载测试，并调整它直到找到正确的值。如果您可以弄清楚如何使用非分布式配额来获得可接受的性能和可预测性，那么这将使您可以使用每秒数而不是每分钟数，这可能会降低大量峰值。
祝你好运！