Annulla la convalida dei contenuti memorizzati nella cache

L'annullamento della convalida della cache (o eliminazione definitiva della cache) è il processo di dichiarare i contenuti memorizzati nella cache non validi. In questo modo, i contenuti vengono rimossi dalla cache, garantendo che la richiesta successiva venga recuperata direttamente dal server di origine.

Media CDN supporta diversi modi per selezionare i contenuti di cui annullare la convalida, come indicato di seguito:

• Host e percorso dell'URL
• Prefisso URL (carattere jolly)
• Tag della cache, inclusi i tag integrati per status, origin e content-type

Puoi combinare questi parametri di annullamento della convalida per individuare specifiche risposte memorizzate nella cache e ridurre al minimo il carico sull'origine durante il successivo riempimento della cache.

Sintassi di annullamento della convalida supportata

La sintassi di annullamento della convalida supportata è la seguente:

Note:

• In una singola richiesta di annullamento della convalida è possibile specificare fino a 10 tag della cache.
• Puoi combinare host, path e tags in una singola richiesta di annullamento della convalida. Vengono trattati come un AND booleano.
• Quando vengono specificati più tag della cache, vengono trattati come un OR booleano. Ad esempio, se specifichi --tags="status=404,origin=staging-origin", tutti le risposte con un tag della cache status=404 vengono invalidati, così come tutte le risposte con un tag della cache origin=staging-origin.

Tag della cache

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

Questi tag sono definiti da quanto segue:

• Impostazione dell'intestazione HTTP Cache-Tag in una risposta di origine, con i tag specificati come elenco separato da virgole di valori.
• Tag integrati basati sul codice di stato HTTP della risposta, sul tipo MIME dall'intestazione della risposta HTTP Content-Type o sul nome dell'origine da cui è stata recuperata la risposta.

Quando in una singola richiesta di annullamento della convalida vengono specificati più tag, questi vengono trattati come un OR booleano.

Considera il seguente esempio:

• Hai i seguenti oggetti memorizzati nella cache:

  • Oggetto memorizzato nella cache n. 1 con i tag status=200, content-type=video/mp4
  • Oggetto memorizzato nella cache n. 2 con i tag status=404, content-type=text/plain
  • Oggetto memorizzato nella cache n. 3 con i tag status=200, content-type=application/x-mpegurl

• Invii una richiesta di annullamento della convalida degli oggetti con tags="status=200,content-type=text/plain"

• Risultato: tutti e tre gli oggetti memorizzati nella cache vengono invalidati contemporaneamente. In questo modo, non è necessario specificare tutte le possibili combinazioni di tag, alcune delle quali potrebbero essere sconosciute.

Note:

• I tag della cache predefiniti non sono inclusi nella risposta rivolta al cliente perché riflettono le intestazioni esistenti (come la riga di stato o Content-Type) o i dettagli di configurazione interni.
• I tag della cache inviati dall'origine nell'intestazione della risposta HTTP Cache-Tag vengono inviati al client. Se vuoi impedire che vengano inviati al client, utilizza la funzionalità responseHeadersToRemove in una routeRule per rimuovere l'intestazione Cache-Tag. Per esempi, consulta la documentazione sulle intestazioni personalizzate.

Tag integrati

Alle risposte vengono applicati automaticamente i seguenti tag della cache per supportare l'annullamento della convalida dei contenuti in base al codice di stato, al tipo MIME o all'origine da cui sono stati recuperati i contenuti. Non è necessario specificare questi tag nelle risposte di origine.

Limitazioni dei tag della cache

I tag della cache presentano le seguenti limitazioni:

• 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, esclusi i tag predefiniti aggiunti da Media CDN
• Deve essere un nome di token HTTP valido, come definito nella sezione 3.2.6 della RFC 7230 HTTP
• Non deve includere i prefissi integrati status=, origin= o content-type= (che vengono ignorati).

I tag che non rientrano in questi limiti o non soddisfano questi requisiti vengono ignorati. In alcuni casi (ad esempio quando le intestazioni delle risposte sono troppo grandi), la risposta non va a buon fine e non viene memorizzata nella cache.

Autorizzazioni

L'networkservices.EdgeCacheServices.invalidateCache autorizzazione controlla l'accesso all'API invalidateCache. Questa autorizzazione è inclusa nei ruoli IAM (Identity and Access Management) networkservices.edgeCacheAdmin e networkservices.edgeCacheUser.

Esempi

Gli esempi seguenti mostrano come invalidare le risposte memorizzate nella cache per un servizio Media CDN.

Puoi combinare i campi host, path e tags in una singola richiesta di annullamento della convalida per invalidare un insieme specifico di contenuti.

Annulla la convalida in base all'host

gcloud edge-cache services invalidate-cache SERVICE_NAME \
    --host=HOST

gcloud edge-cache services invalidate-cache SERVICE_NAME \
    --host="media.example.com"

L'invalidazione di tutti i contenuti associati a un host può essere rischiosa e influire sulle prestazioni. Valuta la possibilità di ridurre l'ambito di invalidazione fornendo un percorso specifico o tag della cache pertinenti.

Annulla la convalida in base al percorso

gcloud edge-cache services invalidate-cache SERVICE_NAME \
    --path=PREFIX

gcloud edge-cache services invalidate-cache SERVICE_NAME \
    --path="/segments/e94a6b1f731/*"

Annulla la convalida in base al tag della cache

gcloud edge-cache services invalidate-cache SERVICE_NAME \
    --tags=TAGS

gcloud edge-cache services invalidate-cache SERVICE_NAME \
    --tags="status=404,content-type=text/plain"

Latenza di invalidazione

L'invalidazione della cache nelle migliaia di località di Media CDN in genere viene completata entro un minuto a livello globale.

In alcuni casi, l'invalidazione può richiedere più tempo, a seconda del carico del sistema, della connettività e del volume di contenuti da invalidare.

Logging

Se i log di audit sono abilitati, le chiamate di invalidazione vengono registrate in Cloud Logging.

Limitazioni

Le invalidazioni sono soggette a limitazione di frequenza. Se superi il limite di frequenza delle invalidazioni, riceverai un messaggio di errore HTTP 429 con lo stato RESOURCE_EXHAUSTED.

Ogni richiesta di invalidazione viene conteggiata come una singola operazione rispetto al limite di frequenza, indipendentemente dalle dimensioni o dall'ambito del percorso. Ad esempio, l'invalidazione di un singolo file (/images/my-image.png) o di un percorso con carattere jolly (/images/*) viene conteggiata come una singola richiesta di invalidazione.