Verwenden Sie die Vergleichstabelle unten, um zu entscheiden, welche Richtlinie für Ihren Ratenbegrenzungs-Anwendungsfall verwendet werden soll:
Kontingent
SpikeArrest
Einsatzzweck:
Begrenzen Sie die Anzahl der API-Proxy-Aufrufe, die eine Entwickler-App oder ein Entwickler in einem bestimmten Zeitraum durchführen kann. Die SpikeArrest-Richtlinie eignet sich besser für die Ratenbegrenzung über kürzere Zeitintervalle wie Sekunden oder Minuten. Ziehen Sie die Kontingentrichtlinie in Betracht, wenn eine genaue Zählung erforderlich ist.
Die Anzahl der API-Aufrufe begrenzen, die über einen bestimmten Zeitraum (normalerweise kurz) für alle Nutzer ausgeführt werden können. Die Kontingentrichtlinie eignet sich besser zum Festlegen von Limits für längere Zeitintervalle wie Tage, Wochen, Monate oder Jahre.
Nicht geeignete Einsatzzwecke:
Nicht verwenden, um das Ziel-Back-End Ihres API-Proxys vor Trafficspitzen zu schützen.
Dazu verwenden Sie die SpikeArrest-Richtlinie.
Nicht verwenden, um die Anzahl der Verbindungen zu erfassen und zu beschränken, die Anwendungen über einen bestimmten Zeitraum zum Ziel-Back-End Ihres API-Proxys herstellen können. Hinweis: Verwenden Sie für alle Anwendungsfälle, bei denen eine genaue Zählung erforderlich ist, die Kontingentrichtlinie.
Anzahl wird gespeichert?
Ja
Nein
Best Practices zum Anhängen der Richtlinie:
Hängen Sie sie an den ProxyEndpoint Request PreFlow an, normalerweise nach der Authentifizierung des Nutzers.
Dadurch kann die Richtlinie den Kontingentzähler am Einstiegspunkt Ihres API-Proxys prüfen.
Hängen Sie sie an den ProxyEndpoint Request PreFlow an, normalerweise ganz am Anfang des Ablaufs.
Dies ermöglicht einen Schutz vor Spitzen am Einstiegspunkt Ihres API-Proxys.
HTTP-Statuscode bei Erreichen des Limits:
429 (Dienst nicht verfügbar)
429 (Dienst nicht verfügbar)
Gut zu wissen:
Der Kontingentzähler wird in Cassandra gespeichert.
Konfigurieren Sie die Richtlinie so, dass der Zähler asynchron synchronisiert wird, um Ressourcen zu speichern.
Eine asynchrone Zählersynchronisierung kann zu einer Verzögerung bei der Ratenbegrenzungsantwort führen. Dadurch werden eventuell etwas mehr Aufrufe als das festgelegte Limit zugelassen.
Hier können Sie zwischen einem "Glättungs"-Algorithmus und einem Maximalwert-Algorithmus wählen. Der erstere glättet die Anzahl der Anfragen, die in einem bestimmten Zeitraum auftreten können, und beim letzteren wird die Gesamtzahl der Anfragen begrenzt, die in einem bestimmten Zeitraum auftreten können, unabhängig davon, wie schnell sie nacheinander gesendet werden. Außerdem wird die Glättung nicht über die Message Processors koordiniert.
[[["Leicht verständlich","easyToUnderstand","thumb-up"],["Mein Problem wurde gelöst","solvedMyProblem","thumb-up"],["Sonstiges","otherUp","thumb-up"]],[["Schwer verständlich","hardToUnderstand","thumb-down"],["Informationen oder Beispielcode falsch","incorrectInformationOrSampleCode","thumb-down"],["Benötigte Informationen/Beispiele nicht gefunden","missingTheInformationSamplesINeed","thumb-down"],["Problem mit der Übersetzung","translationIssue","thumb-down"],["Sonstiges","otherDown","thumb-down"]],["Zuletzt aktualisiert: 2025-09-04 (UTC)."],[[["\u003cp\u003eThis content focuses on the Quota and SpikeArrest policies within Apigee and Apigee hybrid, which are used to manage request thresholds.\u003c/p\u003e\n"],["\u003cp\u003eThe Quota policy is recommended for use cases requiring precise request counting over longer durations like days, weeks, months, or years, offering accurate counting across all regions.\u003c/p\u003e\n"],["\u003cp\u003eSpikeArrest is better suited for rate limiting over short intervals, such as seconds or minutes, and for protecting backend services from sudden traffic spikes, but its request counting may not be entirely accurate due to its use of a Redis cache.\u003c/p\u003e\n"],["\u003cp\u003eBoth the Quota and SpikeArrest policies trigger a \u003ccode\u003e429\u003c/code\u003e (Service Unavailable) HTTP status code when request limits are reached, indicating a temporary denial of service.\u003c/p\u003e\n"],["\u003cp\u003eShared flows and chaining proxies can be utilized to protect slower backends without impacting API performance.\u003c/p\u003e\n"]]],[],null,["# Comparing Quota and SpikeArrest policies\n\n*This page\napplies to **Apigee** and **Apigee hybrid**.*\n\n\n*View [Apigee Edge](https://docs.apigee.com/api-platform/get-started/what-apigee-edge) documentation.*\n\n| **Key Point:** The [Quota](/apigee/docs/api-platform/reference/policies/quota-policy) and [SpikeArrest](/apigee/docs/api-platform/reference/policies/spike-arrest-policy) policies both count requests and take action if a specified request threshold is exceeded. Be aware, however, that the mechanisms by which these policies count requests are not the same.\n|\n|\n| While SpikeArrest maintains counts with high reliability, it is designed to use a\n| [Redis\n| best-effort cache](https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/other_protocols/redis) to store its counts. Because the cache is not replicated, there are cases where counts may be\n| lost, such as a restart of the cache servers, or other rare cases.\n|\n| For these reasons, we recommend\n| against using SpikeArrest for use cases that require accurate counting. Only the synchronous\n| Quota policy offers accurate counting across all regions in a given timeframe.\n\nUse the comparison chart below to help you decide which policy to use to\nfor your rate limiting use case:\n\n| **Tip:** You can also use the following to protect slow/sluggish backends without impacting the performance of the APIs:\n|\n| - [Creating reusable shared flows:](/apigee/docs/api-platform/fundamentals/shared-flows) Combine policies and resources into a shared flow that you can consume from multiple API proxies, and even from other shared flows.\n| - [Chaining API proxies together](/apigee/docs/api-platform/fundamentals/connecting-proxies-other-proxies): Specify that one proxy is the target endpoint of another, effectively connecting the two proxies in a proxy chain. Chaining proxies in this way can help you avoid a network hop, and so improve overall performance."]]
