Antipattern: memorizzare nella cache le risposte di errore

Stai visualizzando la documentazione di Apigee e Apigee hybrid.
Visualizza la documentazione di Apigee Edge.

La memorizzazione nella cache è un processo di archiviazione 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 il recupero più rapido dei dati
  • Riduce il tempo di elaborazione evitando la rigenerazione ripetuta dei dati
  • Impedisce alle richieste API di raggiungere i server di backend e, di conseguenza, riduce il carico aggiuntivo su questi server
  • Consente un migliore utilizzo delle risorse di sistema/dell'applicazione
  • Migliora i tempi di risposta delle API

Ogni volta che dobbiamo accedere di frequente a dati che non cambiano troppo spesso, consigliamo vivamente di utilizzare una cache per memorizzarli.

Apigee offre la possibilità di archiviare i dati in una cache in fase di esecuzione per la persistenza e un recupero più rapido. La funzionalità di memorizzazione nella cache viene resa disponibile tramite i criteri PopulateCache, LookupCache, InvalidateCache e ResponseCache.

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

Il criterio di cache della risposta:

  • 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

La norma ResponseCache ti consente di memorizzare nella cache le risposte HTTP con qualsiasi possibile codice di stato, per impostazione predefinita. Ciò significa che sia le risposte di successo che quelle di errore possono essere memorizzate nella cache.

Ecco un esempio di criterio della cache delle risposte con 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 configurazione predefinita. Tuttavia, non è consigliabile memorizzare nella cache le risposte agli errori senza riflettere attentamente sulle 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.

    OR

  • Scenario 2: gli errori verranno osservati per un periodo di tempo prestabilito, dopodiché dovremo modificare il codice per evitare la memorizzazione nella cache delle risposte una volta risolto il problema

Per spiegare meglio, esaminiamo questi due scenari in dettaglio.

Scenario 1: guasto temporaneo del backend/delle risorse

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

  • Un guasto temporaneo della rete
  • Il server di backend è estremamente occupato e non è in grado di rispondere alle richieste per un periodo di tempo 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 memorizziamo nella cache le risposte di errore, potremmo continuare a inviare risposte di errore agli utenti anche se il problema con il server di backend è stato risolto.

Scenario 2: errore di backend/risorsa protratto o fisso

Tieni presente che sappiamo che l'errore nel backend si verifica per un periodo di tempo prestabilito. Ad esempio, sei consapevole che:

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

    OR

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

Con queste informazioni, possiamo impostare il tempo di scadenza della cache in modo appropriato nel criterio della cache della risposta in modo da non memorizzare nella cache le risposte di errore per un periodo di tempo più lungo. Tuttavia, una volta che il server/la risorsa di backend sarà di nuovo disponibile, dovremo modificare il criterio per evitare di memorizzare nella cache le risposte di errore. Questo perché, in caso di errore temporaneo/una tantum del server di backend, memorizzeremo nella cache la risposta e avremo il problema spiegato nello scenario 1 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 potrebbero dedicare molto tempo 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 memorizzare le risposte di errore nella cache delle risposte. Assicurati che l'elemento <ExcludeErrorResponse> sia impostato su true nel criterio ResponseCache per impedire la memorizzazione nella cache delle risposte di errore, come mostrato nello snippet di codice di seguito. Con questa configurazione verranno memorizzate nella cache solo le risposte per i codici di successo predefiniti da 200 a 205 (a meno che i codici di successo non vengano modificati). 
    <!-- /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 devi memorizzare nella cache le risposte di errore per un motivo specifico, puoi determinare la durata massima/esatta per cui verrà osservato l'errore (se possibile):
    • Imposta il valore Scadenza in modo appropriato per assicurarti di non memorizzare nella cache le risposte agli errori per più tempo rispetto al periodo di visibilità dell'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 si verifica per un breve periodo di tempo/in modo temporaneo.

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