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 con el objetivo de dejar lugar para el contenido nuevo. Te recomendamos que quites un objeto de la caché antes de su tiempo de vencimiento normal. Puedes hacer que la caché ignore un objeto o un conjunto de objetos solicitando una invalidación de caché.

La invalidación de caché, a veces llamada borrado definitivo 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 backend la próxima vez que se solicite el contenido.

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

Puedes combinar estos parámetros de invalidación para orientar 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 devuelva 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 un límite de frecuencia. Puedes enviar hasta 500 solicitudes de invalidación por minuto. Cada una tarda alrededor de 10 segundos en aplicarse.

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

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

Puedes restringir la invalidación a solo uno de los hosts especificándolo.

Invalidación por etiquetas de caché

Las etiquetas de caché (o las claves subrogadas) te permiten invalidar el contenido según 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 exceder 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 valor lógico OR. Considera un ejemplo en el que tienes los siguientes objetos almacenados en caché:

  • Objeto almacenado en caché núm. 1 con las etiquetas js, 2020-12-23 y prod
  • Objeto almacenado en caché núm. 2 con las etiquetas css, 2020-11-30 y prod
  • Objeto almacenado en caché núm. 3 con las 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é núm. 1 con la URL https://staging.example.com/img/cat.jpg y la etiqueta a
  • Objeto almacenado en caché núm. 2 con la URL https://example.com/img/cat.jpg y la etiqueta a
  • Objeto almacenado en caché núm. 3 con la URL https://staging.example.com/js/cat.js y la etiqueta a
  • Objeto almacenado en caché núm. 4 con la URL https://staging.example.com/img/logo.jpg y la etiqueta b

Cuando emites una solicitud para invalidar objetos en los que el host es staging.example.com, la ruta de acceso /img/* y la etiqueta a, solo se invalida el objeto núm. 1. Los objetos núm. 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 cachés entregaron lleguen a las instancias o los buckets 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 URLs diferentes para las distintas versiones del contenido. Para obtener más información sobre los plazos de vencimiento, consulta Fechas de vencimiento y solicitudes de validación.

Invalidación con referencia de servicio entre proyectos de 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 URLs del balanceador de cargas. De forma predeterminada, cuando usas un balanceador de cargas de aplicaciones externo global con referencia del servicio entre proyectos de VPC compartida, los administradores del proyecto de servicio no tendrán los permisos necesarios para solicitar invalidaciones de caché.

Solo pueden emitir invalidaciones de caché las principales que tienen los roles de Identity and Access Management (IAM) para configurar los recursos del balanceador de cargas en los proyectos de frontend, 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 y emitir la invalidación de caché para sus servicios entre proyectos. En el caso de las reescrituras de URLs, 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?