Kontingentrichtlinie und SpikeArrest-Richtlinie im Vergleich

Diese Seite gilt für Apigee und Apigee Hybrid.

Apigee Edge-Dokumentation aufrufen

Wichtiger Hinweis: Die Kontingent- und SpikeArrest-Richtlinien zählen Anfragen und ergreifen Maßnahmen, wenn ein bestimmter Anfragegrenzwert überschritten wird. Beachten Sie jedoch, dass die Mechanismen, mit denen diese Richtlinien Anfragen zählen, nicht identisch sind.

SpikeArrest sorgt zwar für eine hohe Zuverlässigkeit, ist aber für die Verwendung eines Redis-Best-Effort-Caches vorgesehen, mit dem die Zählungen gespeichert werden. Da der Cache nicht repliziert wird, kann es vorkommen, dass Zählungen verloren gehen, z. B. bei einem Neustart der Cache-Server oder in anderen seltenen Fällen.

Aus diesem Grund empfehlen wir die Verwendung von SpikeArrest für Anwendungsfälle, die eine genaue Zählung erfordern. Nur die synchrone Kontingentrichtlinie bietet eine genaue Zählung für alle Regionen in einem bestimmten Zeitraum.

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.
Weitere Details:	Kontingentrichtlinie	SpikeArrest-Richtlinie