Invalidación de caché

La invalidación de caché, a veces llamada eliminación de caché, es el proceso de declarar que el contenido almacenado en caché no es válido. Esto hace que la entrada se quite de la caché y, luego, se vuelva a rellenar desde el servidor de origen la próxima vez que se solicite el contenido.

MediaCDN admite varias formas de seleccionar contenido que se invalidará, de la siguiente manera:

  • Ruta de acceso del host y la URL
  • Prefijo de URL (comodín)
  • Etiquetas de caché, incluidas las etiquetas integradas para status, origin y content-type

Puedes combinar estos parámetros de invalidación para orientar respuestas almacenadas en caché específicas y minimizar la carga de origen en el llenado de caché posterior.

Sintaxis de invalidación compatible

La sintaxis de la invalidación admitida es la siguiente:

Tipo Sintaxis Ejemplo
Invalidación de host Invalida las respuestas almacenadas en caché para el host especificado. gcloud edge-cache services invalidate-cache SERVICE_NAME \
    --host="media.example.com"
Invalidación de ruta de acceso Invalida las respuestas almacenadas en caché para la ruta de acceso o el prefijo de ruta especificados. gcloud edge-cache services invalidate-cache SERVICE_NAME \
    --path="/content/1234/hls/*"
gcloud edge-cache services invalidate-cache SERVICE_NAME \
    --path="/videos/funny.mp4"
Invalidación de etiqueta de caché en código de estado HTTP, nombre de origen o tipo de MIME Invalida respuestas almacenadas en caché con una etiqueta coincidente. Muchas etiquetas se tratan como una OR booleana. 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:

  • Se pueden especificar hasta 10 etiquetas de caché en una sola solicitud de invalidación.
  • Puedes combinar host, path y tags en una sola solicitud de invalidación. Se tratan como un valor booleano AND.
  • Cuando se especifican varias etiquetas de caché, se tratan como un OR booleano. Por ejemplo, si especificas --tags="status=404,origin=staging-origin", todas las respuestas con una etiqueta de caché de status=404 se invalidan, al igual que todas respuestas con una etiqueta de caché de origin=staging-origin

Etiquetas de caché

Las etiquetas de caché (o claves subrogadas) te permiten invalidar el contenido en función de los metadatos arbitrarios.

Estas etiquetas se definen de la siguiente manera:

  • Configurar el encabezado HTTP Cache-Tag en una respuesta de origen, con etiquetas especificadas como una lista de valores separada por comas.
  • Etiquetas integradas basadas en el código de estado HTTP de la respuesta, el tipo de MIME del encabezado de respuesta HTTP Content-Type o el nombre del origen del que se recuperó la respuesta.

Cuando se especifican varias etiquetas en una sola solicitud de invalidación, se tratan como un valor booleano OR.

Considera el siguiente ejemplo:

  • Tienes los siguientes objetos almacenados en caché:

    • Objeto almacenado en caché #1 con etiquetas status=200, content-type=video/mp4
    • Objeto almacenado en caché #2 con las etiquetas status=404, content-type=text/plain
    • Objeto almacenado en caché #3 con etiquetas status=200, content-type=application/x-mpegurl

  • Emite una solicitud para invalidar objetos con tags="status=200,content-type=text/plain"

  • Resultado: Los tres objetos almacenados en caché se invalidan al mismo tiempo. Esto es para evitar tener que especificar todas las combinaciones de etiquetas posibles, algunas de las cuales pueden ser desconocidas.

Notas:

  • Las etiquetas de caché predeterminadas no se incluyen en la respuesta al cliente porque reflejan encabezados existentes (como la línea de estado o Tipo de contenido) o detalles de configuración interna.
  • Las etiquetas de caché que envía el origen en el encabezado de respuesta HTTP Cache-Tag se envían al cliente. Si deseas evitar que se envíen al cliente, usa la función responseHeadersToRemove en un routeRule para quitar el encabezado Cache-Tag. Para ver ejemplos, consulta la documentación de encabezados personalizados.

Etiquetas integradas

Las respuestas tienen automáticamente las siguientes etiquetas de caché aplicadas para admitir la invalidación de contenido según el código de estado, el tipo MIME o el origen del que se recuperó el contenido. No es necesario que especifiques estas etiquetas en las respuestas de origen.

Etiqueta Detalles
status=HTTP_STATUS_CODE

La etiqueta de caché status se establece en función del código de estado HTTP que se muestra de la respuesta almacenada en caché.

Por ejemplo, puedes invalidar todas las respuestas HTTP 404 en caché si especificas status=404 en una solicitud de invalidación.
content-type=MIME_TYPE

La etiqueta de caché content-type se establece en función del tipo de MIME configurado en el encabezado de respuesta HTTP Tipo de contenido.

Por ejemplo, el tipo de MIME de una lista de reproducción de HLS es application/x-mpegURL o vnd.apple.mpegURL.

Esto te permite invalidar tipos específicos de contenido.
origin=ORIGIN_NAME

La etiqueta de caché origin se configura en función del nombre del origen del que se recuperó el contenido.

El valor origin hace referencia al valor de .routing.routeRules[].origin y te permite invalidar el contenido de un servidor de origen que está mal configurado o que tiene un comportamiento erróneo.

Limitaciones de las etiquetas de caché

Las etiquetas de caché tienen las siguientes restricciones:

  • No debe superar los 120 bytes por etiqueta.
  • No debe exceder los 1 KB (1,024 bytes) de nombres de etiquetas en total por objeto almacenado en caché.
  • No deben exceder las 10 etiquetas por objeto, sin incluir las etiquetas predeterminadas que agrega Media CDN.
  • Debe ser un nombre de token HTTP válido, como se define en la sección 3.2.6 de HTTP RFC 7230
  • No debe incluir los prefijos status=, origin= o content-type= integrados (que se ignoran).

Las etiquetas que no se encuentran dentro de estos límites o no cumplen con estos requisitos se ignoran. En algunos casos (como cuando los encabezados de respuesta son demasiado grandes), la respuesta falla y no se almacena en caché.

Permisos

El permiso networkservices.EdgeCacheServices.invalidateCache controla el acceso a la API de invalidateCache. Este permiso se incluye en los roles de Identity and Access Management de networkservices.edgeCacheAdmin y networkservices.edgeCacheUser.

Ejemplos

En los siguientes ejemplos, se muestra cómo invalidar las respuestas almacenadas en caché para un servicio de Media CDN.

Puedes combinar los campos host, path y tags en una sola solicitud de invalidación para invalidar un conjunto específico de contenido.

Invalidar por host

Consola

  1. Ve a la página Media CDN en la consola de Google Cloud.
    Ir a Media CDN
  2. Haga clic en la pestaña Servicios.
  3. Haz clic en tu servicio.
  4. Haz clic en la pestaña Invalidación de caché.
  5. Para el patrón de la ruta de acceso que se debe invalidar, ingresa un nombre de host seguido de una ruta de acceso. Por ejemplo, media.example.com/cats o media.example.com/cat*. El nombre de host no puede incluir *.

gcloud 

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

Reemplaza lo siguiente:

  • SERVICE_NAME por el nombre del servicio almacenamiento en caché perimetral
  • HOST por el nombre de host completo de la entrada de caché que se invalidará.

Por ejemplo:

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

Invalidar por ruta de acceso

Consola

  1. Ve a la página Media CDN en la consola de Google Cloud.
    Ir a Media CDN
  2. Haga clic en la pestaña Servicios.
  3. Haz clic en tu servicio.
  4. Haz clic en la pestaña Invalidación de caché.
  5. Para que el patrón de la ruta se invalide, ingresa una ruta de acceso. Por ejemplo, /videos/funny.mp4 o /segments/e94a6b1f731/*.

gcloud 

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

Reemplaza lo siguiente:

  • SERVICE_NAME por el nombre del servicio almacenamiento en caché perimetral
  • HOST por el nombre de host de las entradas de caché que se invalidarán Para que coincida con cualquier nombre de host, omite la marca del host.
  • PREFIX con un prefijo de ruta que termina en “*” y que coincide con las entradas de caché que se invalidarán.

Por ejemplo:

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

También puedes invalidar una ruta de acceso exacta si omites el carácter * al final. Si pasas --path="/videos/funny.mp4", se invalida la respuesta almacenada en caché (si existe) que coincide con esa ruta de acceso.

Invalidar por etiqueta de caché

Consola

La invalidación por etiqueta de caché no es compatible con la consola de Google Cloud.

gcloud 

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

Reemplaza lo siguiente:

  • SERVICE_NAME por el nombre del servicio almacenamiento en caché perimetral
  • TAGS por una lista de etiquetas separadas por comas.

Por ejemplo:

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

Latencia de invalidación

La invalidación de caché en las miles de ubicaciones de Media CDN se completa en un minuto a nivel global.

En algunos casos, la invalidación puede llevar más tiempo, según la carga del sistema, la conectividad y el volumen de contenido que se invalida.

Registros

Si los registros de auditoría están habilitados, las llamadas de invalidación se registran en Cloud Logging.

Limitaciones

Existen limitaciones para las invalidaciones. Puedes enviar un máximo de diez invalidaciones por minuto. Si excedes la tasa, recibirás un mensaje de error HTTP 429 con el estado RESOURCE_EXHAUSTED.

Sin embargo, una invalidación puede ser de cualquier tamaño. Por ejemplo, la invalidación de /images/my-image.png cuenta como una invalidación. La invalidación de /images/* también cuenta como una invalidación.

Este comportamiento difiere del comportamiento en Cloud CDN. Cloud CDN admite una invalidación por minuto.