Diese Seite wurde von der Cloud Translation API übersetzt.

Anti-Pattern: Cache-Fehlerantworten

Sie sehen die Dokumentation zu Apigee Edge.
Zur Apigee X-Dokumentation weitere Informationen

Caching ist ein Vorgang, bei dem Daten vorübergehend in einem Speicher abgelegt werden, der als Cache bezeichnet wird, um später darauf zuzugreifen. Das Caching von Daten bietet erhebliche Leistungsvorteile:

Beschleunigt den Datenabruf
Verringert die Verarbeitungszeit, da nicht ständig neue Daten generiert werden müssen
Verhindert, dass API-Anfragen die Back-End-Server erreichen, und reduziert so den Aufwand auf den Back-End-Servern
Ermöglicht eine bessere Nutzung von System-/Anwendungsressourcen
Verbessert die Antwortzeiten von APIs

Wenn wir häufig auf Daten zugreifen müssen, die sich nicht allzu oft ändern, empfehlen wir dringend, zum Speichern dieser Daten einen Cache zu verwenden.

Apigee Edge bietet die Möglichkeit, Daten zur Laufzeit in einem Cache zu speichern, um Persistenz und einen schnelleren Abruf zu ermöglichen. Die Caching-Funktion wird über PopulateCache-Richtlinie , LookupCache-Richtlinie, invalidateCache-Richtlinie und ResponseCache-Richtlinie verfügbar gemacht.

In diesem Abschnitt sehen wir uns die Antwort-Cache-Richtlinie an. Mit der Response-Cache-Richtlinie auf der Apigee Edge-Plattform können Sie die Antworten von Back-End-Servern im Cache speichern. Wenn die Clientanwendungen wiederholt Anfragen an dieselbe Back-End-Ressource senden und die Ressource regelmäßig aktualisiert wird, können diese Antworten mit dieser Richtlinie im Cache gespeichert werden. Die Antwort-Cache-Richtlinie hilft bei der Rückgabe der im Cache gespeicherten Antworten und vermeidet folglich eine unnötige Weiterleitung der Anfragen an die Back-End-Server.

Die ResponseCache-Richtlinie:

Reduziert die Anzahl der Anfragen, die das Back-End erreichen
Reduziert die Netzwerkbandbreite
Verbessert die API-Leistung und die Antwortzeiten

Anti-Pattern

Mit der ResponseCache-Richtlinie können Sie HTTP-Antworten standardmäßig mit jedem möglichen Statuscode im Cache speichern. Das bedeutet, dass sowohl Erfolgs- als auch Fehlerantworten im Cache gespeichert werden können.

Hier ein Beispiel für eine Antwort-Cache-Richtlinie mit Standardkonfiguration:

<!-- /antipatterns/examples/1-1.xml -->
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ResponseCache async="false" continueOnError="false" enabled="true" name="TargetServerResponseCache">
  <DisplayName>TargetServer ResponseCache</DisplayName>
  <CacheKey>
    <Key Fragment ref="request.uri" /></CacheKey>
    <Scope>Exclusive</Scope>
    <ExpirySettings>
      <TimeoutInSec ref="flow.variable.here">600</TimeoutInSec>
    </ExpirySettings>
  <CacheResource>targetCache</CacheResource>
</ResponseCache>

Die ResponseCache-Richtlinie speichert Fehlerantworten in der Standardkonfiguration im Cache. Es ist jedoch nicht empfehlenswert, Fehlerantworten im Cache zu speichern, ohne die negativen Auswirkungen zu berücksichtigen:

Szenario 1: Fehler treten für einen vorübergehenden, unbekannten Zeitraum auf und wir senden möglicherweise weiterhin Fehlerantworten aufgrund von Caching, auch nachdem das Problem behoben wurde.
ODER
Szenario 2: Fehler werden für einen festgelegten Zeitraum erfasst. Deshalb müssen wir den Code ändern, um zwischengespeicherte Antworten zu vermeiden, wenn das Problem behoben ist.

Lassen Sie uns dies anhand dieser beiden Szenarien näher erläutern.

Szenario 1: Temporärer Back-End-/Ressourcenfehler

Beachten Sie, dass der Fehler auf dem Back-End-Server auf einen der folgenden Gründe zurückzuführen ist:

Eine vorübergehende Störung im Netzwerk
Der Back-End-Server ist extrem ausgelastet und kann vorübergehend nicht auf Anfragen antworten
Die angeforderte Back-End-Ressource wurde möglicherweise vorübergehend entfernt/nicht verfügbar.
Der Back-End-Server reagiert langsam, weil die Verarbeitungszeit für einen vorübergehenden Zeitraum zu lang ist usw.

In allen diesen Fällen können für einen bestimmten Zeitraum Fehler auftreten. Erst dann können wir erfolgreiche Antworten erhalten. Wenn wir die Fehlerantworten im Cache speichern, senden wir möglicherweise weiterhin Fehlerantworten an die Nutzer, obwohl das Problem mit dem Back-End-Server behoben wurde.

Szenario 2: Überzogener oder behobener Back-End-/Ressourcenfehler

Wir wissen, dass der Fehler im Back-End für einen bestimmten Zeitraum auftritt. Zum Beispiel wissen wir, dass:

Eine bestimmte Back-End-Ressource ist 1 Stunde lang nicht verfügbar
ODER
Der Back-End-Server wird aufgrund eines plötzlichen Websiteausfalls, Skalierungsprobleme, Wartung, Upgrade usw. entfernt oder 24 Stunden lang nicht verfügbar sein.

Mit diesen Informationen können wir die Cache-Ablaufzeit in der Antwort-Cache-Richtlinie entsprechend festlegen, sodass die Fehlerantworten nicht länger im Cache gespeichert werden. Sobald der Back-End-Server bzw. die Back-End-Ressource jedoch wieder verfügbar ist, müssen wir die Richtlinie ändern, um zu verhindern, dass Fehlerantworten im Cache gespeichert werden. Dies liegt daran, dass bei einem vorübergehenden/einmaligen Fehler des Back-End-Servers die Antwort im Cache gespeichert wird und das Problem auftritt, das in Szenario 1 oben erläutert wurde.

Auswirkungen

Caching-Fehlerantworten können dazu führen, dass Fehlerantworten gesendet werden, auch nachdem das Problem auf dem Back-End-Server gelöst wurde.
Nutzer können sehr aufwändig sein, um die Ursache eines Problems zu beheben, ohne zu wissen, dass sie dadurch verursacht wird, dass die Fehlerantworten vom Back-End-Server im Cache gespeichert werden.

Best Practice

Speichern Sie die Fehlerantworten nicht im Antwortcache. Achten Sie darauf, dass das Element <ExcludeErrorResponse> in der ResponseCache-Richtlinie auf true gesetzt ist, um zu verhindern, dass Fehlerantworten im Cache gespeichert werden, wie im folgenden Code-Snippet dargestellt. Bei dieser Konfiguration werden nur die Antworten für die Standarderfolgscodes 200 bis 205 im Cache gespeichert (sofern die Erfolgscodes nicht geändert werden).

<!-- /antipatterns/examples/1-2.xml -->
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ResponseCache async="false" continueOnError="false" enabled="true" name="TargetServerResponseCache">
  <DisplayName>TargetServerResponseCache</DisplayName>
  <CacheKey>
    <KeyFragment ref="request.uri" />
  </CacheKey>
  <Scope>Exclusive</Scope>
  <ExpirySettings>
    <TimeoutinSec ref="flow.variable.here">600</TimeoutinSec>
  </ExpirySettings>
  <CacheResource>targetCache</CacheResource>
  <ExcludeErrorResponse>true</ExcludeErrorResponse>
</ResponseCache>

Wenn es erforderlich ist, die Fehlerantworten aus einem bestimmten Grund im Cache zu speichern, können Sie die maximale/genaue Dauer bestimmen, für die der Fehler beobachtet wird (falls möglich):
- Legen Sie die Ablaufzeit entsprechend fest, damit die Fehlerantworten nicht länger im Cache gespeichert werden, als die Zeit verstrichen ist, für die der Fehler sichtbar ist.
- Verwenden Sie die ResponseCache-Richtlinie, um die Fehlerantworten ohne das Element <ExcludeErrorResponse> im Cache zu speichern.
Tun Sie dies nur, wenn Sie absolut sicher sind, dass der Back-End-Serverausfall nicht für einen kurzen/temporären Zeitraum aufgetreten ist.
Apigee rät davon ab, 5xx-Antworten von Back-End-Servern im Cache zu speichern.