Visão geral da invalidação de cache

Esta página fornece 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 no cache até expirar ou ser excluído para dar espaço a conteúdos novos. Talvez seja necessário remover um objeto do cache antes do prazo de validade normal. É possível forçar um objeto ou conjunto de objetos a ser ignorado pelo cache ao solicitar uma invalidação de cache.

A invalidação de cache, às vezes chamada limpeza de cache, é o processo de declarar que o conteúdo armazenado em cache é inválido. Esse processo fará com que a entrada seja removida do cache e preenchida novamente pelo 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 e comparadores 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 atingir respostas armazenadas em cache específicas e minimizar a carga de back-end no preenchimento de cache subsequente.

É importante verificar se o servidor de back-end está retornando o conteúdo correto antes de solicitar a invalidação de cache. Do contrário, quando o Cloud CDN solicitar o conteúdo de novo, ele poderá armazenar em cache o conteúdo incorreto.

As solicitações de invalidação são limitadas por taxa. É possível enviar até 500 solicitações de invalidação por minuto. Cada solicitação de invalidação leva cerca de 10 segundos para entrar em vigor.

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 disponibilizadas 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 nomes do host. Por exemplo, se example.com e example2.com forem apontados para o mesmo balanceador de carga e /images/cat.jpg for invalidado, example.com/images/cat.jpg e example2.com/images/cat.jpg serão invalidados.

É possível restringir a invalidação a apenas um dos hosts ao especificar o host.

Invalidação por tags de cache

Com tags de cache (ou chaves alternativas), é possível invalidar 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 podem exceder 120 bytes por tag
  • Não podem exceder 4 KiBs (4.096 bytes) de nomes de tags totais por objeto armazenado em cache
  • Não podem 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 armazenado em cache n.º 1 com as tags js, 2020-12-23 e prod
  • Objeto armazenado em cache n.º 2 com as tags css, 2020-11-30 e prod
  • Objeto em cache n.º 3 com as tags img 2020-11-30 e staging

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, não é necessário saber ou especificar todas as combinações de tags possíveis quando para 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 armazenado em cache n.º 1 com URL https://staging.example.com/img/cat.jpg e tag a
  • Objeto armazenado em cache n.º 2 com URL https://example.com/img/cat.jpg e tag a
  • Objeto armazenado em cache n.º 3 com URL https://staging.example.com/js/cat.js e tag a
  • Objeto armazenado em cache n.º 4 com URL https://staging.example.com/img/logo.jpg e tag b

Quando é emitida uma solicitação para invalidar objetos em que o host é staging.example.com, o caminho é /img/* e a tag é a, apenas o objeto n.º 1 é invalidado. Os objetos n.º 2, n.º 3 e n.º 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 ainda não tenha processado a solicitação de invalidação. Essa situação é rara e se corrige 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 disponibilizando para atingir as instâncias ou os buckets de maneira repentina.

A invalidação é usada em circunstâncias excepcionais, não como parte do fluxo de trabalho 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, o projeto que tem a regra de encaminhamento, o proxy de destino e o mapa de URL do balanceador de carga. Portanto, quando é usado 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 do Identity and Access Management (IAM) para configurar recursos do balanceador de carga nos projetos de front-end, por exemplo, o papel de admin de rede do Compute (roles/compute.networkAdmin).

Admins de serviços, que controlam o provisionamento dos serviços de back-end em um projeto separado, trabalham com admins do balanceador de carga do projeto de front-end para emitir a invalidação de cache para serviços entre projetos. Para alterações de URL, verifique se a invalidação corresponde ao host e ao caminho, anteriores à alteração, que o cliente envia.

A seguir