Invalide o conteúdo em cache

A invalidação da cache, por vezes denominada limpeza da cache, é o processo de declarar que o conteúdo em cache é inválido. Isto faz com que a entrada seja removida da cache e, em seguida, preenchida novamente a partir do servidor de origem na próxima vez que o conteúdo for pedido.

A RFC de multimédia suporta várias formas de selecionar conteúdo a ser invalidado, da seguinte forma:

• Anfitrião e caminho de URL
• Prefixo do URL (caractere universal)
• Etiquetas de cache, incluindo etiquetas integradas para status, origin e content-type

Pode combinar estes parâmetros de invalidação para segmentar respostas específicas em cache e minimizar a carga de origem no preenchimento da cache subsequente.

Sintaxe de invalidação suportada

A sintaxe de invalidação suportada é a seguinte:

Tipo	Sintaxe	Exemplo
Invalidação do anfitrião	Invalida as respostas em cache para o anfitrião especificado.	gcloud edge-cache services invalidate-cache SERVICE_NAME \     --host="media.example.com"
Invalidação de caminhos	Invalidar as respostas em cache para o caminho ou o prefixo do caminho especificado.	gcloud edge-cache services invalidate-cache SERVICE_NAME \     --path="/content/1234/hls/*" gcloud edge-cache services invalidate-cache SERVICE_NAME \     --path="/videos/funny.mp4"
Invalidação da etiqueta de cache no código de estado HTTP, no nome de origem ou no tipo MIME	Invalide as respostas em cache com uma etiqueta correspondente. Várias etiquetas são tratadas como um valor booleano OR.	gcloud edge-cache services invalidate-cache SERVICE_NAME \     --tags="status=404,origin=staging-origin" gcloud edge-cache services invalidate-cache SERVICE_NAME \     --tags="content-type=application/x-mpegurl"

Notas:

• É possível especificar até 10 etiquetas de cache num único pedido de invalidação.
• Pode combinar host, path e tags num único pedido de invalidação. São tratados como um valor booleano AND.
• Quando são especificadas várias etiquetas de cache, estas são tratadas como um OR booleano. Por exemplo, se especificar --tags="status=404,origin=staging-origin", todas as respostas com uma etiqueta de cache de status=404 são invalidadas, assim como todas as respostas com uma etiqueta de cache de origin=staging-origin.

Etiquetas de cache

As etiquetas de cache (ou chaves substitutas) permitem-lhe invalidar conteúdo com base em metadados arbitrários.

Nota: as etiquetas de cache são diferentes das chaves de cache.

Estas etiquetas são definidas pelo seguinte:

• Definir o cabeçalho HTTP Cache-Tag numa resposta de origem, com etiquetas especificadas como uma lista de valores separados por vírgulas.
• Tags incorporadas baseadas no código de estado HTTP da resposta, no tipo MIME do cabeçalho da resposta HTTP Content-Type ou no nome da origem a partir da qual a resposta foi obtida.

Quando são especificadas várias etiquetas num único pedido de invalidação, são tratadas como um valor booleano OR.

Considere o seguinte exemplo:

• Tem os seguintes objetos em cache:

  • Objeto n.º 1 em cache com as etiquetas status=200, content-type=video/mp4
  • Objeto em cache n.º 2 com as etiquetas status=404, content-type=text/plain
  • Objeto n.º 3 em cache com as etiquetas status=200, content-type=application/x-mpegurl

• Emite um pedido para invalidar objetos com tags="status=200,content-type=text/plain"

• Resultado: os três objetos em cache são invalidados ao mesmo tempo. Isto destina-se a evitar ter de especificar todas as combinações de etiquetas possíveis, algumas das quais podem ser desconhecidas.

Notas:

• As etiquetas de cache predefinidas não são incluídas na resposta virada para o cliente porque refletem cabeçalhos existentes (como a linha de estado ou o tipo de conteúdo) ou detalhes de configuração internos.
• As etiquetas de cache enviadas pela origem no cabeçalho de resposta HTTP Cache-Tag são enviadas para o cliente. Se quiser impedir que estes sejam enviados para o cliente, use a funcionalidade responseHeadersToRemove num routeRule para remover o cabeçalho Cache-Tag. Para ver exemplos, consulte a documentação sobre os cabeçalhos personalizados.

Etiquetas integradas

As respostas têm automaticamente as seguintes etiquetas de cache aplicadas para suportar a anulação de conteúdo com base no código de estado, no tipo MIME ou na origem a partir da qual o conteúdo foi obtido. Não precisa de especificar estas etiquetas nas respostas de origem.

Etiqueta	Detalhes
status=HTTP_STATUS_CODE	A etiqueta de cache status é definida com base no código de estado HTTP devolvido da resposta em cache. Por exemplo, pode invalidar todas as respostas HTTP 404 em cache especificando status=404 num pedido de invalidação.
content-type=MIME_TYPE	A etiqueta de cache content-type é definida com base no tipo MIME definido no cabeçalho da resposta HTTP Content-Type. Por exemplo, o tipo MIME de uma playlist HLS é application/x-mpegURL ou vnd.apple.mpegURL. Isto permite-lhe invalidar tipos de conteúdo específicos.
origin=ORIGIN_NAME	A etiqueta de cache origin é definida com base no nome da origem a partir da qual o conteúdo foi obtido. O valor origin faz referência ao valor de .routing.routeRules[].origin e permite-lhe invalidar conteúdo de um servidor de origem mal configurado ou com um comportamento potencialmente inadequado.

Limitações das etiquetas de cache

As etiquetas de cache têm as seguintes restrições:

• Não pode exceder 120 bytes por etiqueta
• Não pode exceder 4 KiB (4096 bytes) de nomes de etiquetas totais por objeto em cache
• Não pode exceder 50 etiquetas por objeto, sem incluir as etiquetas predefinidas adicionadas pela RFC de multimédia
• Tem de ser um nome de token HTTP válido, conforme definido na secção 3.2.6 do RFC 7230 HTTP
• Não pode incluir os prefixos incorporados status=, origin= ou content-type= (que são ignorados).

As etiquetas que não se enquadram nestes limites ou não cumprem estes requisitos são ignoradas. Em alguns casos (como quando os cabeçalhos de resposta são demasiado grandes), a resposta falha e não é colocada em cache.

Autorizações

A autorização networkservices.EdgeCacheServices.invalidateCache controla o acesso à API invalidateCache. Esta autorização está incluída nas funções de gestão de identidade e de acesso networkservices.edgeCacheAdmin e networkservices.edgeCacheUser.

Exemplos

Os exemplos seguintes mostram como invalidar respostas em cache para um serviço de CDN de multimédia.

Pode combinar os campos host, path e tags num único pedido de invalidação para invalidar um conjunto específico de conteúdo.

Invalidar por anfitrião

Consola

1. Na Google Cloud consola, aceda à página RFC de multimédia.

   Aceda à RFC de multimédia

2. Clique no separador Serviços.
3. Clique num serviço.
4. Clique no separador Invalidação da cache.
5. Para invalidar a cache por anfitrião, para Anfitrião, especifique um nome de anfitrião, a menos que queira invalidar o caminho para todos os nomes de anfitriões. O nome do anfitrião não pode incluir *.
6. Clique em Invalidar e, de seguida, em Confirmar para indicar que quer que a RFC de multimédia na nuvem invalide o conteúdo correspondente ao anfitrião.

gcloud

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

Substitua o seguinte:

• SERVICE_NAME com o nome do serviço de cache edge.
• HOST com o nome de anfitrião completo da entrada de cache a invalidar.

Por exemplo:

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

A invalidação de todo o conteúdo associado a um anfitrião pode ser arriscada e afetar o desempenho. Pondere reduzir o âmbito da invalidação fornecendo um caminho específico ou etiquetas de cache relevantes.

Anule por caminho

Consola

1. Na Google Cloud consola, aceda à página RFC de multimédia.

   Aceda à RFC de multimédia

2. Clique no separador Serviços.
3. Clique num serviço.
4. Clique no separador Invalidação da cache.
5. Para invalidar a cache por caminho, em Caminho, especifique o caminho e o nome do ficheiro, por exemplo,/videos/funny.mp4 ou /segments/e94a6b1f731/*.
6. Clique em Anular.

gcloud

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

Substitua o seguinte:

• SERVICE_NAME com o nome do serviço de cache edge.
• HOST com o nome do anfitrião das entradas de cache a invalidar. Para corresponder a qualquer nome de anfitrião, omita a flag host.
• PREFIX com um prefixo de caminho que termina em "*" que corresponde às entradas da cache a invalidar.

Por exemplo:

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

Também pode invalidar um caminho exato omitindo o caráter * final. A transmissão de --path="/videos/funny.mp4" invalida a resposta em cache (se existir) correspondente a esse caminho.

Anule por etiqueta de cache

Nota: use o anfitrião, o caminho e as etiquetas em conjunto para reduzir o volume de conteúdo em cache invalidado em simultâneo. As respostas invalidadas são novamente obtidas na íntegra a partir da origem, e a invalidação de demasiado conteúdo em simultâneo pode resultar num aumento da carga no servidor de origem.

Consola

1. Na Google Cloud consola, aceda à página RFC de multimédia.

   Aceda à RFC de multimédia

2. Clique no separador Serviços.
3. Clique num serviço.
4. Clique no separador Invalidação da cache.
5. Para validar a cache por etiquetas, em Etiquetas de cache, especifique uma ou mais etiquetas para invalidar a cache. Use espaços ou vírgulas para separar etiquetas. Pode adicionar um máximo de 10 etiquetas de cache para invalidação.
6. Clique em Anular.

gcloud

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

Substitua o seguinte:

• SERVICE_NAME com o nome do serviço de cache edge.
• TAGS com uma lista de etiquetas separadas por vírgulas.

Por exemplo:

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

Latência de invalidação

A invalidação da cache nas milhares de localizações da RFC de meios normalmente é concluída no prazo de um minuto a nível global.

Em alguns casos, a invalidação pode demorar mais tempo, consoante a carga do sistema, a conetividade e o volume de conteúdo a ser invalidado.

Registo

Se os registos de auditoria estiverem ativados, as chamadas de invalidação são registadas no Cloud Logging.

Limitações

As invalidações estão limitadas por taxa. Se exceder o limite de taxa de invalidações, recebe uma mensagem de erro HTTP 429 com o estado RESOURCE_EXHAUSTED.

Uma invalidação pode ter qualquer tamanho. Por exemplo, invalidar /images/my-image.png conta como uma invalidação. A invalidação de /images/* também conta como uma invalidação.