Nesta página, você encontrará uma visão geral da invalidação de cache do Cloud CDN.
O que é invalidação de cache?
Depois que um objeto é armazenado em cache, ele costuma permanecer em cache até expirar ou ser excluído para dar espaço a conteúdos novos. É possível remover um objeto do cache antes do prazo normal de validade. Para forçar um objeto ou conjunto de objetos a ser ignorado pelo cache, solicite uma invalidação de cache.
A invalidação de cache, às vezes chamada de purga de cache, é o processo de declarar o conteúdo armazenado em cache como inválido. Esse processo faz com que a entrada seja removida do cache e reabastecida do servidor de back-end na próxima vez que o conteúdo for solicitado.
O Cloud CDN oferece suporte ao uso de tags de cache (pré-lançamento) e validadores de invalidação, como host e caminho do URL, para solicitações de invalidação.
É possível combinar esses parâmetros de invalidação para segmentar respostas específicas em cache e minimizar a carga do back-end no preenchimento de cache subsequente.
É importante garantir que o servidor de back-end esteja retornando o conteúdo correto antes de solicitar a invalidação de cache. Caso contrário, quando o Cloud CDN solicitar o conteúdo de novo, ele poderá armazenar o conteúdo incorreto em cache.
As solicitações de invalidação são limitadas por taxa da seguinte maneira:
- Para tags de cache (Preview), é possível enviar até 500 solicitações de invalidação por minuto. Cada solicitação de invalidação entra em vigor em cerca de 10 segundos.
- Para outros comparadores de invalidação, é possível enviar no máximo uma invalidação por minuto. Cada solicitação de invalidação entra em vigor em cerca de um a três minutos.
O Cloud CDN não restringe o número de objetos nem o tamanho total de todos os objetos invalidados para cada solicitação.
Invalidação por URLs
Cada solicitação de invalidação especifica um padrão de caminho que identifica o objeto ou conjunto de objetos a ser invalidado. O padrão de caminho pode ser um caminho específico, como /cat.jpg
, ou uma estrutura de diretório inteira, como /pictures/*
. As regras a seguir se aplicam a padrões de caminho:
- O padrão de caminho precisa começar com
/
. - Não é possível incluir
?
ou#
. - Não é possível incluir um
*
, exceto como o caractere final após um/
. - Se terminar com
/*
, a string anterior é um prefixo e todos os objetos com caminhos que comecem com esse prefixo são invalidados.
O padrão de caminho é comparado ao componente de caminho do URL, que é tudo entre o nome do host e qualquer ?
ou #
que possa estar presente.
Se você tiver URLs que contenham uma string de consulta, por exemplo, /images.php?image=fred.png
, não será possível invalidar objetos seletivamente diferentes por string de consulta. Por exemplo, se você tiver duas imagens, /images.php?image=fred.png
e /images.php?image=barney.png
, não será possível invalidar apenas fred.png
. Para invalidar todas as imagens exibidas por images.php, use /images.php
como padrão de caminho.
Invalidação para um único host
A invalidação de cache se aplica aos caminhos de todos os seus nomes de host. Por exemplo, se você tiver example.com
e example2.com
apontados para o mesmo balanceador de carga e invalidar /images/cat.jpg
, tanto example.com/images/cat.jpg
quanto example2.com/images/cat.jpg
serão invalidados.
É possível restringir a invalidação a apenas um dos hosts adicionando a sinalização --host
ao comando.
Invalidação por tags de cache
As tags de cache (ou chaves substitutas) permitem invalidar o conteúdo com base em metadados arbitrários.
Essas tags são definidas com o cabeçalho HTTP Cache-Tag
em uma resposta
de back-end. As tags de cache do back-end no cabeçalho de resposta HTTP Cache-Tag
são enviadas ao cliente.
As tags de cache têm os seguintes limites:
- Não pode exceder 120 bytes por tag
- Não pode exceder 4 KiB (4096 bytes) de nomes de tags no total por objeto armazenado em cache
- Não pode exceder 50 tags por objeto
Se esses limites de tag forem excedidos, a resposta não será armazenada em cache e essa
decisão será registrada como RESPONSE_CACHE_TAG_INVALID
em
LoadBalancerLogEntry.cacheDecision
.
É possível especificar até 10 tags de cache por solicitação de invalidação. Quando várias tags
são especificadas em uma única solicitação de invalidação, elas são tratadas como um
OR
lógico. Considere um exemplo em que você tem os seguintes objetos em cache:
- Objeto 1 em cache com as tags
js
,2020-12-23
eprod
- Objeto 2 em cache com as tags
css
,2020-11-30
eprod
- Objeto 3 em cache com as tags
img
2020-11-30
estaging
Quando você emite uma solicitação para invalidar objetos que correspondem a
tags="prod,2020-11-30"
, todos os três objetos armazenados em cache são invalidados.
Com essa abordagem, você não precisa saber ou especificar todas as combinações possíveis de tags quando quiser invalidar um objeto.
Se você especificar comparadores de invalidação com tags de cache, a solicitação de invalidação será aplicada apenas aos objetos marcados que correspondem aos comparadores de invalidação. Considere um exemplo com os seguintes objetos armazenados em cache:
- Objeto 1 em cache com URL
https://staging.example.com/img/cat.jpg
e taga
- Objeto em cache 2 com URL
https://example.com/img/cat.jpg
e taga
- Objeto 3 em cache com URL
https://staging.example.com/js/cat.js
e taga
- Objeto 4 em cache com URL
https://staging.example.com/img/logo.jpg
e tagb
Quando você emite uma solicitação para invalidar objetos que correspondem a
--host="staging.example.com" --path="/img/*" --tags="a"
, apenas o objeto 1 é
invalidado. Os objetos 2, 3 e 4 não correspondem ao host, ao caminho ou à tag, respectivamente.
Latência de invalidação
Como o Cloud CDN é um sistema distribuído, ele pode relatar que uma invalidação foi concluída mesmo que um número pequeno de caches não tenha processado a solicitação de invalidação ainda. Esta situação é extremamente rara e se corrigirá automaticamente.
Práticas recomendadas
Invalide apenas o que for preciso, porque muitas invalidações podem causar um pico nas solicitações que os caches estavam exibindo para atingir suas instâncias ou buckets de maneira repentina.
A invalidação é usada em circunstâncias excepcionais, não como parte do fluxo normal. As invalidações não afetam as cópias em cache nos caches do navegador da Web ou em caches operados por provedores de serviços à Internet de terceiros.
Como alternativa às invalidações de rotina, é possível definir proativamente os prazos de validade adequados nas respostas ou usar URLs distintos para versões diferentes do conteúdo. Para mais informações sobre os prazos de validade, consulte Prazos de validade e solicitações de validação.
Invalidação com referência de serviço entre projetos da VPC compartilhada
A invalidação de cache é configurada no projeto de front-end, ou seja, no projeto que tem a regra de encaminhamento, o proxy de destino e o mapa de URL do balanceador de carga. Portanto, quando você usa um balanceador de carga de aplicativo externo global com referência de serviço entre projetos da VPC compartilhada, por padrão, os administradores do projeto de serviço não têm as permissões necessárias para solicitar invalidações de cache.
As invalidações de cache só podem ser emitidas por principais que tenham os papéis de gerenciamento de identidade e acesso (IAM, na sigla em inglês) para configurar recursos do balanceador de carga nos projetos de front-end, por exemplo, o papel de administrador de rede do Compute (roles/compute.networkAdmin
).
Os administradores de serviços, que controlam o provisionamento dos serviços de back-end em um projeto separado, podem trabalhar com o administrador do balanceador de carga do projeto de front-end para emitir a invalidação de cache para os serviços entre projetos. Para substituições de URL, verifique se a invalidação corresponde ao host e ao caminho de pré-regravação que o cliente envia.
A seguir
Para saber como invalidar o conteúdo armazenado no cache do Cloud CDN, consulte Como invalidar conteúdo armazenado em cache.
Para saber qual conteúdo é armazenável em cache ou não, consulte Visão geral do armazenamento em cache.