Anti-pattern: memorizzare le risposte di errore nella cache

Stai visualizzando la documentazione relativa a Apigee e Apigee ibrido.
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 notevoli vantaggi in termini di prestazioni, in quanto:

  • Consente di recuperare più rapidamente i dati
  • Riduce il tempo di elaborazione evitando la rigenerazione dei dati più volte
  • Impedisce alle richieste API di raggiungere i server di backend e quindi riduce l'overhead sui server di backend
  • Consente un migliore utilizzo delle risorse di sistema/applicazione
  • Migliora i tempi di risposta delle API

Se dobbiamo accedere frequentemente ad alcuni dati che non cambiano troppo spesso, consigliamo vivamente di archiviare questi dati con una cache.

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

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

Criteri di Response Cache:

  • 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 nella cache le risposte HTTP con qualsiasi possibile codice di stato. Ciò significa che sia le risposte di successo che quelle di errore possono essere memorizzate nella cache.

Ecco un criterio di Response Cache 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 Response Cache memorizza nella cache le risposte di errore nella sua configurazione predefinita. Tuttavia, non è consigliabile memorizzare nella cache le risposte di errore senza una riflessione considerevole sulle implicazioni negative perché:

  • 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 la memorizzazione nella cache delle risposte 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:

  • 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 dell'elevato tempo di elaborazione per un periodo temporaneo e così via

In tutti questi casi, gli errori potrebbero verificarsi per un periodo di tempo sconosciuto e quindi 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 prolungato o corretto

Tieni presente che l'errore nel backend dura un periodo di tempo prefissato. Ad esempio, sai che:

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

    OR

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

Con queste informazioni, possiamo impostare la scadenza della cache in modo appropriato nel criterio Cache di risposta, in modo da non memorizzare nella cache le risposte di errore per un periodo di tempo più lungo. Tuttavia, quando il server/la risorsa di backend sarà nuovamente disponibile, dovremo modificare il criterio per evitare la memorizzazione nella cache delle risposte di errore. Questo perché se si verifica un errore temporaneo/una tantum dal server di backend, memorizzeremo nella cache la risposta e finiremo con il problema spiegato nello scenario 1 precedente.

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 grandi sforzi alla risoluzione 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 diResponseCache per evitare che le risposte di errore vengano memorizzate nella cache, come mostrato nello snippet di codice riportato di seguito. Con questa configurazione, verranno memorizzate nella cache solo le risposte per i codici di operazione riuscita predefiniti da 200 a 205 (a meno che i codici di operazione 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 hai il requisito di memorizzare nella cache le risposte di errore per un motivo specifico, puoi determinare la durata massima/esatta per cui si verificherà l'errore (se possibile):
    • Imposta la scadenza in modo appropriato per assicurarti di non memorizzare nella cache le risposte di errore per un periodo più lungo rispetto al periodo in cui l'errore può essere visualizzato.
    • 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 o temporaneo.

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