Anti-Pattern: Cache-Fehlerantworten

Sie lesen gerade die Dokumentation zu Apigee und Apigee Hybrid.
Apigee Edge-Dokumentation aufrufen.

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 Sie häufig auf Daten zugreifen, die sich nicht oft ändern, empfehlen wir, diese Daten im Cache zu speichern.

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

In diesem Abschnitt sehen wir uns die ResponseCache-Richtlinie an. Mit der ResponseCache-Richtlinie auf der Apigee-Plattform können Sie die Antworten von Backend-Servern im Cache 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 ein Beispiel für eine ResponseCache-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 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.

Diese beiden Szenarien werden im Folgenden näher erläutert.

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.

Anhand dieser Informationen können wir die Cache-Ablaufzeit in der ResponseCache-Richtlinie entsprechend festlegen, sodass die Fehlerantworten nicht für längere Zeit 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 Fehlerantworten nicht im Antwort-Cache. 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, um die Fehlerantworten nur so lange im Cache zu speichern, wie 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.