Diese Seite wurde von der Cloud Translation API übersetzt.

Anti-Pattern: Cache-Fehlerantworten

<ph type="x-smartling-placeholder"></ph> Sie sehen die Dokumentation zu Apigee Edge.
Gehen Sie 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 Backend-Server erreichen, sodass der Overhead auf Backend-Servern reduziert wird
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 die Verwendung eines Cache zum Speichern dieser Daten.

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

In diesem Abschnitt werfen wir einen Blick auf die Antwort-Cache-Richtlinie. Die Antwort-Cache-Richtlinie in Apigee Edge ermöglicht es Ihnen, die Antworten von Back-End-Servern im Cache zu speichern. Wenn die Clientanwendungen wiederholt Anfragen an dieselbe Backend-Ressource senden und die Ressource regelmäßig aktualisiert wird, können wir diese Antworten mithilfe dieser Richtlinie im Cache speichern. Die ResponseCache-Richtlinie hilft bei der Rückgabe der im Cache gespeicherten Antworten und verhindert daher unnötige Anfragen an die Backend-Server.

Die ResponseCache-Richtlinie:

Reduziert die Anzahl der Anfragen, die das Backend 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 sehen Sie ein Beispiel für eine Antwort-Cache-Richtlinie mit der 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 temporären, unbekannten Zeitraum auf. Wir senden möglicherweise weiterhin Fehlerantworten aufgrund von Caching, selbst wenn 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.

Sehen wir uns diese beiden Szenarien genauer an.

Szenario 1: Temporärer Backend-/Ressourcenfehler

Beachten Sie, dass der Fehler auf dem Backend-Server eine der folgenden Ursachen hat:

Eine vorübergehende Störung im Netzwerk
Der Backend-Server ist sehr ausgelastet und kann vorübergehend nicht auf die Anfragen antworten.
Die angeforderte Backend-Ressource ist vorübergehend nicht verfügbar/vorhanden.
Die Reaktionszeit des Backend-Servers ist aufgrund einer hohen Verarbeitungszeit vorübergehend verzögert.

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 Fehlermeldungen an die Nutzer, obwohl das Problem mit dem Backend-Server behoben wurde.

Szenario 2: Beendeter oder behobener Backend-/Ressourcenfehler

Beachten Sie, dass wir wissen, dass der Fehler im Backend nur für einen bestimmten Zeitraum auftritt. Zum Beispiel wissen wir, dass:

Eine bestimmte Backend-Ressource 1 Stunde lang nicht verfügbar ist
ODER
Der Backend-Server aufgrund von plötzlichen Website-Fehlern, Skalierungsproblemen, Wartungen, Upgrades usw. 24 Stunden lang entfernt wurde bzw. nicht verfügbar ist.

Mit diesen Informationen können wir die Ablaufzeit des Cache im Antwortcache entsprechend einstellen. damit die Fehlerantworten nicht länger im Cache gespeichert werden. Sobald der Backend-Server bzw. die Ressource wieder verfügbar ist, müssen wir die Richtlinie jedoch ändern, um das Caching von Fehlerantworten zu vermeiden. Dies liegt daran, dass bei einem vorübergehenden oder einmaligen Ausfall des Backend-Servers die Antwort im Cache gespeichert wird und dadurch das in Szenario 1 beschriebene Problem auftritt.

Auswirkungen

Fehlerantworten im Cache zu speichern, kann dazu führen, dass Fehlerantworten auch dann gesendet werden, wenn das Problem auf dem Backend-Server behoben wurde.
Nutzer verbringen oft viel Zeit mit der Behebung von Fehlern, ohne zu wissen, dass das Problem durch Caching der Fehlerantworten des Backend-Servers verursacht wird.

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 im Cache gespeichert werden. länger als die Zeit ist, in der 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 Fehler des Backend-Servers nicht für einen kurzen oder temporären Zeitraum andauert.
Apigee empfiehlt, keine 5xx-Antworten von Backend-Servern im Cache zu speichern.