Invalidar contenido almacenado en caché

La invalidación de caché, a veces denominada purgado de caché, es el proceso de declarar que el contenido almacenado en caché no es válido. Esto provoca que la entrada se elimine de la caché y, a continuación, se vuelva a rellenar desde el servidor de origen la próxima vez que se solicite el contenido.

Media CDN admite varias formas de seleccionar el contenido que se va a invalidar, como se indica a continuación:

• Host y ruta de URL
• Prefijo de URL (comodín)
• Etiquetas de caché, incluidas las etiquetas integradas de status, origin y content-type

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

Sintaxis de invalidación admitida

La sintaxis de invalidación admitida es la siguiente:

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.
• Si se especifican varias etiquetas de caché, se tratarán como un valor booleano OR. Por ejemplo, si especificas --tags="status=404,origin=staging-origin", se invalidarán todas las respuestas con la etiqueta de caché status=404, así como todas las respuestas con la etiqueta de caché origin=staging-origin.

Etiquetas de caché

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

Estas etiquetas se definen de la siguiente manera:

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

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

Veamos un ejemplo:

• Tienes los siguientes objetos almacenados en caché:

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

• Envías 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. De esta forma, no es necesario especificar todas las combinaciones de etiquetas posibles, algunas de las cuales podrían ser desconocidas.

Notas:

• Las etiquetas de caché predeterminadas no se incluyen en la respuesta visible para el cliente porque reflejan encabezados (como la línea de estado o Content-Type) o detalles de configuración internos.
• Las etiquetas de caché enviadas por el origen en el encabezado de respuesta HTTP Cache-Tag se envían al cliente. Si quieres 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 sobre encabezados personalizados.

Etiquetas integradas

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

Limitaciones de las etiquetas de caché

Las etiquetas de caché tienen las siguientes restricciones:

• No debe superar los 120 bytes por etiqueta.
• No debe superar los 4 KiB (4096 bytes) de nombres de etiquetas totales por objeto almacenado en caché.
• No debe superar las 50 etiquetas por objeto, sin incluir las etiquetas predeterminadas añadidas por la CDN multimedia.
• Debe ser un nombre de token HTTP válido, tal 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 ajusten a estos límites o no cumplan estos requisitos se ignorarán. En algunos casos (por ejemplo, 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 invalidateCache. Este permiso se incluye en los roles de networkservices.edgeCacheAdmin y networkservices.edgeCacheUser de gestión de identidades y accesos.

Ejemplos

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

Puede 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

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

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

Invalidar todo el contenido asociado a un host puede ser arriesgado y afectar al rendimiento. Te recomendamos que reduzcas el ámbito de invalidación proporcionando una ruta específica o etiquetas de caché relevantes.

Invalidar por ruta

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

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

Invalidar por etiqueta de caché

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"

Latencia de invalidación

La invalidación de la caché en las miles de ubicaciones de Media CDN suele completarse en un minuto en todo el mundo.

En algunos casos, la invalidación puede tardar más tiempo en función de la carga del sistema, la conectividad y el volumen de contenido que se esté invalidando.

Almacenamiento de registros

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

Limitaciones

Las invalidaciones están limitadas por la frecuencia. Si superas el límite de frecuencia de invalidaciones, recibirás un mensaje de error HTTP 429 con el estado RESOURCE_EXHAUSTED.

Una invalidación puede ser de cualquier tamaño. Por ejemplo, invalidar /images/my-image.png cuenta como una invalidación. Invalidar /images/* también cuenta como una invalidación.