Panoramica dell'annullamento della 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 vi rimane fino alla scadenza o finché non viene rimosso per fare spazio a nuovi contenuti. Potresti voler rimuovere un oggetto dalla cache prima della sua normale scadenza. Puoi fare in modo che un oggetto o un insieme di oggetti vengano ignorati dalla cache richiedendo l'annullamento della convalida della cache.

L'annullamento della convalida della cache, a volte chiamato eliminazione definitiva della cache, è il processo di dichiarare i contenuti memorizzati nella cache non validi. Con questo processo, la voce viene rimossa dalla cache e poi riempita caricandola dal server di backend la volta successiva che i contenuti vengono richiesti.

Cloud CDN supporta l'utilizzo di tag della cache e matcher di annullamento della convalida, ad esempio host e percorso URL, per le richieste di annullamento della convalida.

Puoi combinare questi parametri di annullamento della convalida per individuare specifiche risposte memorizzate nella cache 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'annullamento della convalida della cache. In caso contrario, quando Cloud CDN richiede di nuovo i contenuti, potrebbe memorizzare nella cache i contenuti errati.

Le richieste di annullamento della convalida sono soggette a limitazione di frequenza. Puoi inviare fino a 500 richieste di annullamento della convalida al minuto. Ogni richiesta di annullamento della convalida ha effetto in circa 10 secondi.

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

Annullamento della convalida per URL

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

  • Il pattern del percorso deve iniziare con /.
  • Non può includere ? o #.
  • Non deve includere un simbolo *, a meno che non sia il carattere finale dopo un simbolo /.
  • 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 qualsiasi ? o # eventualmente presente.

Se hai URL che contengono una stringa di query, ad esempio /images.php?image=fred.png, non puoi invalidare selettivamente 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 puoi invalidare solo fred.png. Per invalidare tutte le immagini pubblicate da images.php, utilizza /images.php come pattern del percorso.

Annullamento della convalida per un singolo host

L'annullamento della convalida della cache invalida il percorso per tutti i tuoi nomi host. Ad esempio, se hai example.com e example2.com che puntano allo stesso bilanciatore del carico e annulli la convalida di /images/cat.jpg, vengono invalidati sia example.com/images/cat.jpg che example2.com/images/cat.jpg.

Puoi limitare l'annullamento della convalida a un solo host specificando l'host.

Annullamento della convalida in base ai tag della cache

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

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

I tag della cache presentano i seguenti limiti:

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

Se questi limiti dei 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 della cache per richiesta di annullamento della convalida. Quando in una singola richiesta di annullamento della convalida vengono specificati più tag, questi vengono trattati come un OR logico. Considera un esempio in cui hai i seguenti oggetti memorizzati nella cache:

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

Quando invii una richiesta di annullamento della convalida degli oggetti che corrispondono a tags="prod,2020-11-30", tutti e tre gli oggetti memorizzati nella cache vengono invalidati. Questo approccio significa che non devi conoscere o specificare tutte le possibili combinazioni di tag quando vuoi invalidare un oggetto.

Se specifichi i matcher di annullamento della convalida insieme ai tag della cache, la richiesta di annullamento della convalida si applica solo agli oggetti taggati che corrispondono ai matcher di annullamento della convalida. Considera un esempio con i seguenti oggetti memorizzati nella cache:

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

Quando invii una richiesta di annullamento della convalida degli oggetti in cui l'host è staging.example.com, il percorso /img/* e il tag a, viene invalidato solo l'oggetto n. 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

Annulla la convalida solo se è strettamente necessario, perché un utilizzo eccessivo della funzionalità potrebbe causare un picco nelle richieste servite dalle cache, che può colpire improvvisamente le tue istanze o i tuoi bucket.

L'annullamento della convalida va utilizzato in circostanze eccezionali, non come parte del normale flusso di lavoro. L'annullamento della convalida non influisce sulle copie memorizzate nella cache delle cache dei browser web o nelle cache gestite da provider di servizi internet di terze parti.

In alternativa agli annullamenti della convalida di routine, puoi impostare in modo proattivo tempi di scadenza appropriati per le risposte o utilizzare URL diversi per versioni diverse dei tuoi contenuti. Per saperne di più sui tempi di scadenza, consulta la sezione Tempi di scadenza e richieste di convalida.

Annullamento della convalida con riferimento ai servizi tra progetti con VPC condiviso

L'annullamento della convalida della cache si configura nel progetto frontend, ovvero il progetto che contiene la regola di forwarding, il proxy di destinazione e la mappa URL del bilanciatore del carico. Pertanto, quando utilizzi un bilanciatore del carico delle applicazioni esterno globale con riferimento ai servizi tra progetti con VPC condiviso, per impostazione predefinita gli amministratori v non dispongono delle autorizzazioni necessarie per richiedere annullamenti della convalida della cache.

Gli annullamenti della convalida della cache possono essere richiesti solo da entità che dispongono dei ruoli Identity and Access Management (IAM) per la configurazione di risorse bilanciatore 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 separato, possono collaborare con l'amministratore del bilanciatore del carico del progetto frontend per richiedere l'annullamento della convalida della cache per i propri servizi tra progetti. Per le riscritture di URL, assicurati che l'annullamento della convalida corrisponda all'host e al percorso inviati dal client prima della riscrittura.

Passaggi successivi