Quoten- und SpikeArrest-Richtlinien – mit der Frage, welche verwendet werden soll
Ihren Anforderungen an die
Ratenbegrenzung am besten entspricht? Siehe die Vergleichstabelle unten.
Kontingent
SpikeArrest
Einsatzzweck:
Begrenzen Sie die Anzahl der Verbindungen, die Apps mit dem Ziel-Back-End Ihres API-Proxys über eine
für einen bestimmten Zeitraum.
Schützen Sie das Ziel-Back-End Ihres API-Proxys vor starken Trafficspitzen und Ablehnung von
von Angriffen.
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.
Verwenden Sie dazu 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:
500 (Interner Serverfehler) *
500 (Interner Serverfehler) *
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.
Führt eine Drosselung basierend auf der Zeit aus, zu der der letzte Traffic empfangen wurde. Diese Zeit wird pro Nachrichtenverarbeiter gespeichert.
Wenn Sie eine Ratenbegrenzung von 100 Aufrufen pro Sekunde angeben, wird für den Nachrichtenverarbeiter nur ein Aufruf pro 1/100 Sekunde (10 ms) zugelassen. Ein zweiter Aufruf innerhalb von 10 ms wird abgelehnt.
Selbst bei einer hohen Ratenbegrenzung pro Sekunde können fast parallele Anfragen zu Ablehnungen führen.
* Für die Kontingentrichtlinie und die SpikeArrest-Richtlinie ist der standardmäßige HTTP-Statuscode für das Überschreiten der Ratenbegrenzung ein allgemeiner 500 Internal Server Error.
Sie können den Statuscode für diese Richtlinien in
429 Service Unavailable, indem Sie Folgendes hinzufügen:
Property auf Organisationsebene (features.isHTTPStatusTooManyRequestEnabled).
Wenn Sie Cloud-Kunde sind, wenden Sie sich an den Apigee Edge-Support, um die Eigenschaft aktivieren zu lassen.
