Panoramica dell'annullamento convalida della cache

Questa pagina fornisce una panoramica dell'annullamento della convalida della cache di Cloud CDN.

Che cos'è l'annullamento della convalida della cache?

Una volta memorizzato nella cache, un oggetto normalmente rimane al suo interno fino alla scadenza o viene espulso per fare spazio a nuovi contenuti. Potresti voler rimuovere un oggetto dalla cache prima della sua normale scadenza. Puoi forzare la cache a ignorare un oggetto o un insieme di oggetti richiedendo l'annullamento della convalida della cache.

L'annullamento della convalida della cache, a volte chiamato pulizia della cache, è il processo di dichiarazione di non validità dei contenuti memorizzati nella cache. Questo processo fa sì che la voce venga rimossa dalla cache e poi reintegrata dal server di backend alla successiva richiesta dei contenuti.

Cloud CDN supporta l'utilizzo di tag cache (Anteprima) e di corrispondenze di invalidazione, come host e percorso dell'URL, per le richieste di invalidazione.

Puoi combinare questi parametri di invalidazione per scegliere come target risposte memorizzate nella cache specifiche e ridurre al minimo il carico sul backend durante il successivo riempimento della cache.

È importante assicurarsi che il server di backend restituisca i contenuti corretti prima di richiedere l'invalidazione della cache. In caso contrario, quando Cloud CDN richiede di nuovo i contenuti, potrebbe memorizzare nella cache i contenuti errati.

Le richieste di invalidazione sono limitate come segue:

  • Per i tag cache (Anteprima), puoi inviare fino a 500 richieste di invalidazione al minuto. Ogni richiesta di annullamento dell'aggiornamento diventa effettiva in circa 10 secondi.
  • Per altri corrispondenti di convalida, puoi inviare al massimo una convalida al minuto. Ogni richiesta di annullamento dell'aggiornamento viene applicata in circa 1-3 minuti.

Cloud CDN non limita il numero di oggetti o le dimensioni totali di tutti gli oggetti invalidati per ogni richiesta.

Mancata convalida per URL

Ogni richiesta di annullamento della convalida specifica un pattern di percorso che identifica l'oggetto o l'insieme di oggetti da annullare. Il pattern del percorso può essere un percorso specifico, ad esempio /cat.jpg, o un'intera struttura di directory, ad esempio /pictures/*. Ai pattern di percorso si applicano le seguenti regole:

  • Il pattern del percorso deve iniziare con /.
  • Non può includere ? o #.
  • Non deve includere un *, tranne come carattere finale dopo un /.
  • Se termina con /*, la stringa precedente è un prefisso e tutti gli oggetti i cui percorsi iniziano con quel prefisso vengono invalidati.

Il pattern del percorso viene confrontato con il componente del percorso dell'URL, ovvero tutto ciò che si trova tra il nome host e eventuali ? o #.

Se hai URL che contengono una stringa di query, ad esempio/images.php?image=fred.png, non puoi invalidare in modo selettivo gli oggetti che differiscono solo per la stringa di query. Ad esempio, se hai due immagini,/images.php?image=fred.png e /images.php?image=barney.png, non puoifred.png. Per invalidare tutte le immagini pubblicate da images.php, utilizza /images.php come pattern percorso.

Annullamento per un singolo host

L'invalidamento della cache rende non valido il percorso per tutti i nomi host. Ad esempio, se hai impostato example.com e example2.com in modo che puntino allo stesso bilanciatore del carico e invalidi /images/cat.jpg, sia example.com/images/cat.jpg che example2.com/images/cat.jpg vengono invalidati.

Puoi limitare l'invalidazione a uno solo degli host aggiungendo il flag --host al comando.

Annullamento della convalida tramite tag della cache

I tag della cache (o chiavi sostitutive) ti consentono di invalidare i contenuti in base a metadati arbitrari.

Questi tag sono definiti con l'intestazione HTTP Cache-Tag in una risposta del backend. I tag della cache dal backend nell'intestazione della risposta HTTP Cache-Tag vengono inviati al client.

I tag cache hanno i seguenti limiti:

  • Non deve superare i 120 byte per tag
  • Non deve superare i 4 KiB (4096 byte) di nomi di tag totali per oggetto memorizzato nella cache
  • Non devono superare i 50 tag per oggetto

Se questi limiti di tag vengono superati, la risposta non viene memorizzata nella cache e questa decisione viene registrata come RESPONSE_CACHE_TAG_INVALID in LoadBalancerLogEntry.cacheDecision.

Puoi specificare fino a 10 tag cache per richiesta di invalidazione. Quando più tag vengono specificati in una singola richiesta di convalida, vengono trattati come un OR logico. Considera un esempio in cui hai i seguenti oggetti memorizzati nella cache:

  • Oggetto 1 memorizzato nella cache con i tag js, 2020-12-23 e prod
  • Oggetto 2 memorizzato nella cache con i tag css, 2020-11-30 e prod
  • Oggetto memorizzato nella cache 3 con i tag img 2020-11-30 e staging

Quando emetti una richiesta di invalidazione degli oggetti corrispondenti atags="prod,2020-11-30", vengono invalidati tutti e tre gli oggetti memorizzati nella cache. Questo approccio significa che non devi conoscere o specificare tutte le possibili combinazioni di tag quando vuoi invalidare un oggetto.

Se specifichi i corrispondenti di invalidazione insieme ai tag cache, la richiesta di invalidazione si applica solo agli oggetti taggati che corrispondono ai corrispondenti di invalidazione. Prendiamo ad esempio i seguenti oggetti memorizzati nella cache:

  • Oggetto memorizzato nella cache 1 con URL https://staging.example.com/img/cat.jpg e tag a
  • Oggetto memorizzato nella cache 2 con URL https://example.com/img/cat.jpg e tag a
  • Oggetto memorizzato nella cache 3 con URL https://staging.example.com/js/cat.js e tag a
  • Oggetto memorizzato nella cache 4 con URL https://staging.example.com/img/logo.jpg e tag b

Quando emetti una richiesta di invalidazione degli oggetti corrispondenti a--host="staging.example.com" --path="/img/*" --tags="a", viene invalidato solo l'oggetto 1. Gli oggetti 2, 3 e 4 non corrispondono rispettivamente all'host, al percorso o al tag.

Latenza di annullamento della convalida

Poiché Cloud CDN è un sistema distribuito, potrebbe segnalare che un annullamento della convalida è stato completato anche se un numero ridotto di cache non ha ancora elaborato la richiesta di annullamento della convalida. Questa situazione è rara e si corregge automaticamente.

Best practice

Annullare l'aggiornamento solo di ciò che è necessario, perché annullare l'aggiornamento di troppi elementi potrebbe causare un picco improvviso delle richieste che le cache stavano servendo nelle tue istanze o nei tuoi bucket.

L'invalidazione è pensata per essere utilizzata in circostanze eccezionali, non nell'ambito del normale flusso di lavoro. Le invalidazioni non influiscono sulle copie memorizzate nella cache nelle cache dei browser web o nelle cache gestite da provider di servizi internet di terze parti.

In alternativa alle invalidazioni di routine, puoi impostare in modo proattivo scadenze appropriate per le risposte o utilizzare URL diversi per versioni diverse dei tuoi contenuti. Per ulteriori informazioni sulle date di scadenza, consulta Date di scadenza e richieste di convalida.

Mancata convalida con il riferimento ai servizi tra progetti con VPC condiviso

L'annullamento della convalida della cache è configurato nel progetto frontend, ovvero nel progetto con la regola di inoltro, il proxy di destinazione e la mappa URL del bilanciatore del carico. Pertanto, quando utilizzi un Application Load Balancer esterno globale con riferimento a servizi tra progetti VPC condiviso, per impostazione predefinita gli amministratori dei progetti di servizio non dispongono delle autorizzazioni necessarie per richiedere l'invalidazione della cache.

L'invalidazione della cache può essere emessa solo dalle entità che dispongono dei ruoli IAM per la configurazione delle risorse di bilanciamento del carico nei progetti frontend, ad esempio il ruolo Compute Network Admin (roles/compute.networkAdmin).

Gli amministratori dei servizi, che controllano il provisioning dei servizi di backend in un progetto distinto, possono collaborare con l'amministratore del bilanciatore del carico del progetto frontend per emettere l'invalidazione della cache per i propri servizi tra progetti. Per le riscritture degli URL, assicurati che l'invalidazione corrisponda all'host e al percorso pre-riscrittura inviati dal client.

Passaggi successivi