问题
We're using a spikearrest policy but we don't understand how is working. The spike arrest configuration is the following:
<SpikeArrest enabled="true" continueOnError="true" async="false" name="SpikeArrest">
<Rate>5pm</Rate>
<MessageWeight ref="request.header.weight"/>
</SpikeArrest>
Reading the documentation, we understand that if we call more than 5 times this flow in a minute, the policy will fail in the calls after the 5th. But, when we tested it with 10 calls in less than 10 seconds, the policy accepts the first two calls and fails in the next calls. Can you explain us why is this happening? Can this be related to that the environment has 2 message processors and 2 routers?
回答1:
Spike Arrest of 5 per minute means it will allow a maximum of 5 messages per minute and equally distribute those 5 messages over the span of a minute i.e 1 message is allowed in each 12 secs window of a minute.Now if the spike arrest counters are not being synced across two message processors and it is strict round robin then the value of messages allowed per time unit will be doubled, which in your case maybe 2 messages in 12 secs, hence the noticed behaviour.
回答2:
Spike arrests aren't implemented as counts. They are currently implemented as rate limiting based on the time the last matching traffic was successfully processed.
If you specify 5 per minute, it means that your requests can only come in one per 12 sec (1/5 minute). A second request within 12 sec on the same message processor will be rejected. Even with a larger number (100 per second), if two requests come in nearly simultaneously to the same message processor, one will be rejected. Each successful (non-arrested) request will update the spike arrest's last processed count.
Also, each message processor tracks a separate time.
You should probably look into quotas if you want values in the tens per minute range.
回答3:
Think of Spike Arrest as a way to generally protect against traffic spikes rather than as a way to limit traffic to a specific number of requests. Your APIs and backend can handle a certain amount of traffic, and the Spike Arrest policy helps you smooth traffic to the general amounts you want.
The runtime Spike Arrest behavior differs from what you might expect to see from the literal per-minute or per-second values you enter.
For example, say you enter a rate of 30pm (30 requests per minute). In testing, you might think you could send 30 requests in 1 second, as long as they came within a minute. But that's not how the policy enforces the setting. If you think about it, 30 requests inside a 1-second period could be considered a mini spike in some environments.
What actually happens, then? To prevent spike-like behavior, Spike Arrest smooths the number of full requests allowed by dividing your settings into smaller intervals:
Per-minute rates get smoothed into full requests allowed in intervals of seconds. For example, 30pm gets smoothed like this: 60 seconds (1 minute) / 30pm = 2-second intervals, or 1 request allowed every 2 seconds. A second request inside of 2 seconds will fail. Also, a 31st request within a minute will fail.
Per-second rates get smoothed into full requests allowed in intervals of milliseconds. For example, 10ps gets smoothed like this: 1000 milliseconds (1 second) / 10ps = 100-millisecond intervals, or 1 request allowed every 100 milliseconds. A second request inside of 100ms will fail. Also, an 11th request within a second will fail.
There's more: 1 request * number of message processors Spike Arrest is not distributed, so request counts are not synchronized across message processors. With more than one message processor, especially those with a round-robin configuration, each handles its own Spike Arrest throttling independently. With one message processor, a 30pm rate smooths traffic to 1 request every 2 seconds (60 / 30). With two message processors (the default for Edge cloud), that number doubles to 2 requests every 2 seconds. So multiply your calculated number of full requests per interval by the number of message processors to get your overall arrest rate.
来源：https://stackoverflow.com/questions/21912316/apigee-spikearrest-behavior