Kontingentrichtlinie und SpikeArrest-Richtlinie im Vergleich

Sie sehen sich die Dokumentation zu Apigee Edge an.
Sehen Sie sich die Apigee X-Dokumentation an. info

Kontingent- und SpikeArrest-Richtlinien – Sie möchten wissen, welche dieser Richtlinien am besten Ihre Anforderungen an die Ratenbegrenzung erfüllt? Siehe die Vergleichstabelle unten.

Kontingent SpikeArrest
Einsatzzweck: Die Anzahl der Verbindungen beschränken, die Anwendungen für einen bestimmten Zeitraum zum Ziel-Back-End Ihres API-Proxys herstellen können. Das Ziel-Back-End Ihres API-Proxys vor starken Trafficspitzen und Denial-of-Service-Angriffen schützen.
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.
Weitere Details: Kontingentrichtlinie SpikeArrest-Richtlinie

* 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 auf 429 Too Many Requests ändern, indem Sie ein Attribut auf Organisationsebene (features.isHTTPStatusTooManyRequestEnabled) hinzufügen. Wenn Sie Cloud-Kunde sind, wenden Sie sich an den Apigee Edge-Support, damit das Attribut aktiviert wird.