Anti-pattern: risposte agli errori nella cache

Stai visualizzando la documentazione di Apigee Edge.
Vai alla documentazione di Apigee X. informazioni

La memorizzazione nella cache è un processo di memorizzazione temporanea dei dati in un'area di archiviazione chiamata cache per riferimento futuro. La memorizzazione nella cache dei dati offre vantaggi significativi in termini di prestazioni perché:

  • Consente di recuperare più rapidamente i dati
  • Riduce il tempo di elaborazione evitando la rigenerazione dei dati
  • Impedisce alle richieste API di raggiungere i server di backend, riducendo così l'overhead sui server di backend
  • Consente un migliore utilizzo delle risorse del sistema/delle applicazioni
  • Migliora i tempi di risposta delle API

Ogni volta che dobbiamo accedere di frequente ad alcuni dati che non cambiano troppo spesso, consigliamo vivamente di utilizzare una cache per archiviare questi dati.

Apigee Edge offre la possibilità di archiviare i dati in una cache in fase di runtime per garantire la persistenza e un recupero più rapido. La funzionalità di memorizzazione nella cache è resa disponibile tramite il criterio PopulateCache, il criterio LookupCache, il criterio InvalidateCache e il criterioResponseCache.

In questa sezione esamineremo il criterio della cache delle risposte. Il criterio Cache di risposte nella piattaforma Apigee Edge consente di memorizzare nella cache le risposte dei server di backend. Se le applicazioni client effettuano richieste alla stessa risorsa di backend ripetutamente e la risorsa viene aggiornata periodicamente, possiamo memorizzare le risposte nella cache utilizzando questo criterio. Il criterio Cache di risposte aiuta a restituire le risposte memorizzate nella cache e, di conseguenza, evita di inoltrare le richieste ai server di backend inutilmente.

Il criterio della cache delle risposte:

  • Riduce il numero di richieste che raggiungono il backend
  • Riduce la larghezza di banda della rete
  • Migliora le prestazioni e i tempi di risposta dell'API

Antipattern

Per impostazione predefinita, il criterioResponseCache consente di memorizzare le risposte HTTP con qualsiasi codice di stato possibile. Ciò significa che sia le risposte di errore che quelle riuscite possono essere memorizzate nella cache.

Ecco un criterio della cache delle risposte di esempio con la configurazione predefinita:

<!-- /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>

Il criterio Cache delle risposte memorizza nella cache le risposte di errore nella sua configurazione predefinita. Tuttavia, non è consigliabile memorizzare nella cache le risposte di errore senza considerare attentamente le implicazioni negative perché:

  • Scenario 1: si verificano errori per un periodo temporaneo e sconosciuto e potremmo continuare a inviare risposte di errore a causa della memorizzazione nella cache anche dopo la risoluzione del problema

    OPPURE

  • Scenario 2: gli errori verranno osservati per un periodo di tempo fisso. Dovremo modificare il codice per evitare la memorizzazione nella cache delle risposte una volta risolto il problema

Spieghiamo questo concetto esaminando questi due scenari in modo più dettagliato.

Scenario 1: errore temporaneo del backend/delle risorse

Considera che l'errore nel server di backend è dovuto a uno dei seguenti motivi:

  • Si è verificato un problema di rete temporaneo
  • Il server di backend è estremamente occupato e non è in grado di rispondere alle richieste per un periodo temporaneo
  • La risorsa di backend richiesta potrebbe essere rimossa/non disponibile per un periodo di tempo temporaneo
  • Il server di backend risponde lentamente a causa di un tempo di elaborazione elevato per un periodo temporaneo e così via

In tutti questi casi, gli errori potrebbero verificarsi per un periodo di tempo sconosciuto, dopodiché potremmo iniziare a ricevere risposte positive. Se le risposte di errore vengono memorizzate nella cache, potremmo continuare a inviare risposte di errore agli utenti anche se il problema con il server di backend è stato risolto.

Scenario 2: errore prolungato o corretto del backend/delle risorse

Ricorda che sappiamo che l'errore del backend è riferito a un periodo di tempo fisso. Ad esempio, sai che:

  • Una risorsa di backend specifica non sarà disponibile per 1 ora

    OPPURE

  • Il server di backend è stato rimosso/non disponibile per 24 ore a causa di un guasto improvviso del sito, problemi di scalabilità, manutenzione, upgrade e così via.

Con queste informazioni, possiamo impostare correttamente la scadenza della cache nel criterio Cache delle risposte, in modo da non memorizzare le risposte di errore nella cache per più tempo. Tuttavia, una volta che il server/risorsa di backend sarà di nuovo disponibile, dovremo modificare il criterio per evitare le risposte di errore di memorizzazione nella cache. Questo perché, se si verifica un errore temporaneo/una tantum del server di backend, la risposta verrà memorizzata nella cache e alla fine verrà restituito il problema descritto nello scenario 1 riportato sopra.

Impatto

  • La memorizzazione nella cache delle risposte di errore può causare l'invio di risposte di errore anche dopo che il problema è stato risolto nel server di backend
  • Gli utenti possono dedicare molto impegno alla risoluzione della causa di un problema senza sapere che è causato dalla memorizzazione nella cache delle risposte di errore del server di backend

Best practice

  • Non archiviare le risposte di errore nella cache delle risposte. Assicurati che l'elemento <ExcludeErrorResponse> sia impostato su true nel criterio ResponseCache per evitare che le risposte di errore vengano memorizzate nella cache, come mostrato nello snippet di codice riportato di seguito. Con questa configurazione, solo le risposte per i codici di operazione riuscita predefiniti da 200 a 205 (a meno che non vengano modificati i codici di operazione riuscita) vengono memorizzate nella cache. 
    <!-- /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>
  • Se per qualche motivo specifico hai il requisito di memorizzare nella cache le risposte di errore, puoi determinare la durata massima o esatta per cui si verificherà l'errore, se possibile:
    • Imposta la data di scadenza in modo appropriato per assicurarti di non memorizzare le risposte di errore nella cache per un periodo superiore a quello per cui è visibile l'errore.
    • Utilizza il criterio ResponseCache per memorizzare nella cache le risposte di errore senza l'elemento <ExcludeErrorResponse>.

    Esegui questa operazione solo se hai la certezza assoluta che l'errore del server di backend non sia di breve durata/temporaneo.

  • Apigee non consiglia di memorizzare nella cache le risposte 5xx dei server di backend.