Anti-pattern: risposte agli errori nella cache

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 comporta notevoli vantaggi in termini di rendimento perché:

  • Consente di recuperare più rapidamente i dati
  • Riduce i tempi di elaborazione evitando la rigenerazione dei dati più e più volte
  • 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 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 Criterio ResponseCache.

In questa sezione diamo un'occhiata al criterio della cache di risposta. Il criterio Cache di risposta nella piattaforma Apigee consente di memorizzare nella cache le risposte dei server di backend. Se le applicazioni client fanno 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 risposta è utile per restituire le risposte memorizzate nella cache e, di conseguenza, per evitare di inoltrare inutilmente le richieste ai server di backend.

Il criterio della cache di risposta:

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

Antipattern

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

Ecco un criterio della cache delle risposte di esempio 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 risposte memorizza nella cache le risposte di errore nella sua configurazione predefinita. Tuttavia, non è consigliabile memorizzare le risposte di errore nella cache senza considerare le implicazioni avverse, in quanto:

  • Scenario 1: gli errori si verificano 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 fisso, quindi dovremo modificare il codice per evitare risposte nella cache una volta risolto il problema

Spieghiamo meglio questi due scenari.

Scenario 1: errore temporaneo del backend o delle risorse

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

  • Si è verificato un glitch 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 tempi di elaborazione elevati 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 corrette. Se le risposte di errore vengono memorizzate nella cache, gli utenti potrebbero continuare a inviare risposte di errore anche se il problema con il server di backend è stato risolto.

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

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

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

    OR

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

Con queste informazioni possiamo impostare correttamente la scadenza della cache nel criterio Response Cache, in modo da non memorizzare le risposte di errore nella cache per un periodo più lungo. Tuttavia, quando il server/la risorsa di backend saranno di nuovo disponibili, dovremo modificare il criterio per evitare le risposte di errore di memorizzazione nella cache. Questo perché in caso di errore temporaneo/una tantum dal server di backend, la risposta verrà memorizzata nella cache e troveremo il problema descritto nello scenario 1 riportato sopra.

Impatto

  • La memorizzazione delle risposte di errore nella cache può causare l'invio delle risposte di errore anche dopo che il problema è stato risolto nel server di backend
  • Gli utenti possono dedicare molto lavoro a risolvere la causa di un problema senza sapere che è causato dalla memorizzazione nella cache delle risposte di errore dal 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 i codici di operazione riuscita) vengano 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 hai il requisito di memorizzare nella cache le risposte di errore per qualche motivo specifico, puoi determinare la durata massima o esatta per cui verrà osservato l'errore (se possibile):
    • Imposta l'ora di scadenza in modo appropriato per assicurarti di non memorizzare nella cache le risposte di errore per un periodo superiore a quello per cui è possibile visualizzare 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 durerà a breve/temporaneo.

  • Apigee non consiglia la memorizzazione nella cache di risposte 5xx dai server di backend.