Descripción general de la invalidación de caché

En esta página, se proporciona una descripción general de la invalidación de caché de Cloud CDN.

¿Qué es la invalidación de caché?

Una vez que un objeto se almacena en caché, por lo general, permanece en la caché hasta su vencimiento o expulsión a fin de dejar lugar para el contenido nuevo. Te recomendamos que quites un objeto de la caché antes de su plazo de vencimiento normal. Puedes hacer que la caché ignore un objeto o un conjunto de objetos mediante la solicitud de una 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. Este proceso hace que la entrada se quite de la caché y, luego, se vuelva a rellenar desde el servidor de backend la próxima vez que se solicite el contenido.

Cloud CDN admite el uso de etiquetas de caché (Versión preliminar) y comparadores de invalidación, como el host y la ruta de URL, para las solicitudes de invalidación.

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

Es importante asegurarse de que el servidor de backend muestre el contenido correcto antes de solicitar la invalidación de la caché. De lo contrario, cuando Cloud CDN vuelva a solicitar el contenido, podría almacenar en caché el contenido incorrecto.

Las solicitudes de invalidación tienen una limitación de frecuencia de la siguiente manera:

  • En el caso de las etiquetas de caché (Versión preliminar), puedes enviar hasta 500 solicitudes de invalidación por minuto. Cada solicitud de invalidación se aplica en aproximadamente 10 segundos.
  • Para otros comparadores de invalidaciones, puedes enviar una invalidación por minuto como máximo. Cada solicitud de invalidación se aplica en aproximadamente uno a tres minutos.

Cloud CDN no restringe la cantidad de objetos ni el tamaño total de todos los objetos invalidados para cada solicitud.

Invalidación por URLs

Cada solicitud de invalidación especifica un patrón de ruta de acceso que identifica el objeto o el conjunto de objetos que debe invalidarse. El patrón de ruta de acceso puede ser una ruta específica, como /cat.jpg, o una estructura de directorio completa, como /pictures/*. Las siguientes reglas se aplican a los patrones de ruta de acceso:

  • El patrón de ruta de acceso debe comenzar con /.
  • No puede incluir ? ni #.
  • No debe incluir un *, excepto como el carácter final después de una /.
  • Si termina con /*, la string anterior es un prefijo, y todos los objetos cuyas rutas de acceso comienzan con ese prefijo se invalidan.

El patrón de la ruta de acceso se compara con el componente de la ruta de la URL, que es todo lo que existe entre el nombre del host y cualquier ? o # que pueda estar presente.

Si tienes URL que contienen una cadena de consulta, por ejemplo, /images.php?image=fred.png, no puedes invalidar de manera selectiva los objetos que difieren solo por la cadena de consulta. Por ejemplo, si tienes dos imágenes, /images.php?image=fred.png y /images.php?image=barney.png, no puedes invalidar solo fred.png. Para invalidar todas las imágenes que entrega images.php, usa /images.php como patrón de ruta de acceso.

Invalidación para un solo host

La invalidación de la caché invalida la ruta de acceso para todos los nombres de host. Por ejemplo, si example.com y example2.com apuntan al mismo balanceador de cargas y, luego, invalidas /images/cat.jpg; example.com/images/cat.jpg y example2.com/images/cat.jpg se invalidarán.

Puedes restringir la invalidación a solo uno de los hosts; para ello, agrega la marca --host al comando.

Invalidación por 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 con el encabezado HTTP Cache-Tag en una respuesta del backend. Las etiquetas de caché del backend en el encabezado de respuesta HTTP Cache-Tag se envían al cliente.

Las etiquetas de caché tienen los siguientes límites:

  • No debe superar los 120 bytes por etiqueta.
  • No debe exceder los 4 KiB (4,096 bytes) de nombres de etiquetas en total por objeto almacenado en caché.
  • No debe superar las 50 etiquetas por objeto.

Si se superan estos límites de etiquetas, la respuesta no se almacena en caché y esta decisión se registra como RESPONSE_CACHE_TAG_INVALID en LoadBalancerLogEntry.cacheDecision.

Puedes especificar hasta 10 etiquetas de caché por solicitud de invalidación. Cuando se especifican varias etiquetas en una sola solicitud de invalidación, se tratan como un OR lógico. Considera un ejemplo en el que tienes los siguientes objetos almacenados en caché:

  • Objeto almacenado en caché #1 con etiquetas js, 2020-12-23 y prod
  • Objeto almacenado en caché #2 con las etiquetas css, 2020-11-30 y prod
  • Objeto almacenado en caché #3 con etiquetas img, 2020-11-30 y staging

Cuando emites una solicitud para invalidar objetos que coinciden con tags="prod,2020-11-30", se invalidan los tres objetos almacenados en caché. Este enfoque significa que no necesitas conocer ni especificar todas las combinaciones de etiquetas posibles cuando deseas invalidar un objeto.

Si especificas comparadores de invalidación junto con etiquetas de caché, la solicitud de invalidación solo se aplica a los objetos etiquetados que coinciden con los comparadores de invalidación. Considera un ejemplo con los siguientes objetos almacenados en caché:

  • Objeto almacenado en caché #1 con la URL https://staging.example.com/img/cat.jpg y la etiqueta a
  • Objeto almacenado en caché #2 con la URL https://example.com/img/cat.jpg y la etiqueta a
  • Objeto almacenado en caché #3 con la URL https://staging.example.com/js/cat.js y la etiqueta a
  • Objeto almacenado en caché #4 con la URL https://staging.example.com/img/logo.jpg y la etiqueta b

Cuando emites una solicitud para invalidar objetos que coinciden con --host="staging.example.com" --path="/img/*" --tags="a", solo se invalida el objeto n° 1. Los objetos 2, 3 y 4 no coinciden con el host, la ruta de acceso ni la etiqueta, respectivamente.

Latencia de invalidación

Debido a que Cloud CDN es un sistema distribuido, podría informar que una invalidación se completó aunque una pequeña cantidad de cachés aún no haya procesado la solicitud de invalidación. Esta situación es poco frecuente y se corrige de forma automática.

Prácticas recomendadas

Solo realiza las invalidaciones que sean necesarias, ya que realizar demasiadas invalidaciones podría provocar que una gran cantidad de solicitudes que las memorias caché entregaron lleguen a las instancias o los depósitos de forma repentina.

La invalidación está diseñada para usarse en circunstancias excepcionales, no como parte del flujo de trabajo normal. Las invalidaciones no afectan a las copias almacenadas en las cachés de navegadores web ni en las cachés que operan los Proveedores de servicios de Internet de terceros.

Como alternativa a las invalidaciones de rutina, puedes establecer de manera proactiva plazos de vencimiento adecuados en las respuestas o usar URL diferentes para las distintas versiones del contenido. Para obtener más información sobre los plazos de vencimiento, consulta Plazos de vencimiento y solicitudes de validación.

Anulación con la referencia de servicio entre proyectos de la VPC compartida

La invalidación de caché se configura en el proyecto de frontend, es decir, el proyecto que tiene la regla de reenvío, el proxy de destino y el mapa de URL del balanceador de cargas. Por lo tanto, cuando usas un balanceador de cargas de aplicaciones externo global con referencia de servicios entre proyectos de VPC compartida, de forma predeterminada, los administradores del proyecto de servicio no tienen los permisos necesarios para solicitar invalidaciones de caché.

Solo las principales que tienen los roles de IAM para configurar los recursos del balanceador de cargas en los proyectos de frontend pueden emitir invalidaciones de caché, por ejemplo, el rol de administrador de red de Compute (roles/compute.networkAdmin).

Los administradores de servicios, que controlan el aprovisionamiento de los servicios de backend en un proyecto separado, pueden trabajar con el administrador del balanceador de cargas del proyecto de frontend para emitir la invalidación de caché para sus servicios entre proyectos. Para las reescrituras de URL, asegúrate de que la invalidación coincida con el host y la ruta de acceso previos a la reescritura que envía el cliente.

¿Qué sigue?