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

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

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

Una vez que se almacena en caché un objeto, normalmente permanece en la caché hasta que caduca o se elimina para dejar espacio a contenido nuevo. Puede que quieras eliminar un objeto de la caché antes de su fecha de caducidad normal. Puedes forzar que la caché ignore un objeto o un conjunto de objetos solicitando una invalidación de la 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. Este proceso provoca que la entrada se elimine de la caché y, a continuación, se vuelva a rellenar desde el servidor backend la próxima vez que se solicite el contenido.

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

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

Es importante asegurarse de que el servidor backend devuelve 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 están limitadas por la frecuencia. Puedes enviar hasta 500 solicitudes de invalidación por minuto. Cada solicitud de invalidación tarda unos 10 segundos en aplicarse.

Cloud CDN no restringe el número de objetos ni el tamaño total de todos los objetos invalidado por cada solicitud.

Invalidación por URLs

Cada solicitud de invalidación especifica un patrón de ruta que identifica el objeto o el conjunto de objetos que se deben invalidar. El patrón de ruta puede ser una ruta específica, como /cat.jpg, o una estructura de directorios completa, como /pictures/*. Las rutas se rigen por las siguientes reglas:

  • El patrón de ruta debe empezar por /.
  • No puede incluir ? ni #.
  • No debe incluir *, excepto como carácter final después de /.
  • Si termina con /*, la cadena anterior es un prefijo y todos los objetos cuyas rutas empiecen por ese prefijo se invalidarán.

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

Si tiene URLs que contienen una cadena de consulta, por ejemplo, /images.php?image=fred.png, no puede invalidar de forma selectiva objetos que solo se diferencien en 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 sirve images.php, usa /images.php como patrón de ruta.

Invalidación de un solo host

La invalidación de caché invalida la ruta de todos tus nombres de host. Por ejemplo, si tienes example.com y example2.com que apuntan al mismo balanceador de carga y invalidas /images/cat.jpg, se invalidarán tanto example.com/images/cat.jpg como example2.com/images/cat.jpg.

Puedes restringir la invalidación a uno de los hosts especificando el host.

Invalidación por etiquetas de caché

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

Estas etiquetas se definen con el encabezado HTTP Cache-Tag en una respuesta de 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 superar los 4 KiBs (4096 bytes) de nombres de etiquetas totales 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 almacenará en caché y esta decisión se registrará como RESPONSE_CACHE_TAG_INVALID en LoadBalancerLogEntry.cacheDecision.

Puedes especificar hasta 10 etiquetas de caché por solicitud de invalidación. Si se especifican varias etiquetas en una sola solicitud de invalidación, se tratarán como un OR lógico. Supongamos que tienes los siguientes objetos en caché:

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

Cuando envías una solicitud para invalidar objetos que coincidan con tags="prod,2020-11-30", se invalidan los tres objetos almacenados en caché. Con este enfoque, no es necesario que conozcas ni especifiques todas las combinaciones de etiquetas posibles cuando quieras invalidar un objeto.

Si especifica invalidadores junto con etiquetas de caché, la solicitud de invalidación solo se aplica a los objetos etiquetados que coincidan con los invalidadores. Veamos un ejemplo con los siguientes objetos almacenados en caché:

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

Cuando envías una solicitud para invalidar objetos en los que el host es staging.example.com, la ruta /img/* y la etiqueta a, solo se invalida el objeto 1. Los objetos 2, 3 y 4 no coinciden con el host, la ruta o la etiqueta, respectivamente.

Latencia de invalidación

Como Cloud CDN es un sistema distribuido, puede informar de que una invalidación se ha completado aunque un pequeño número de cachés aún no haya procesado la solicitud de invalidación. Esta situación es poco habitual y se corrige automáticamente.

Prácticas recomendadas

Invalida solo lo que sea necesario, ya que si invalidas demasiado contenido, puede que se produzca un pico en las solicitudes que las cachés estaban sirviendo y que, de repente, afecte a tus instancias o contenedores.

La invalidación se debe usar en circunstancias excepcionales, no como parte de tu flujo de trabajo habitual. Las invalidaciones no afectan a las copias almacenadas en caché en las cachés de los navegadores web ni en las cachés gestionadas por proveedores de servicios de Internet de terceros.

Como alternativa a las invalidaciones rutinarias, puede definir de forma proactiva tiempos de vencimiento adecuados en las respuestas o usar URLs diferentes para las distintas versiones de su contenido. Para obtener más información sobre los tiempos de vencimiento, consulta Tiempos de vencimiento y solicitudes de validación.

Invalidación con referencia de servicios entre proyectos de VPC compartida

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

Las invalidaciones de caché solo pueden emitirlas las entidades que tengan los roles de Gestión de Identidades y Accesos (IAM) para configurar recursos de balanceador de carga en los proyectos de frontend. Por ejemplo, el rol Administrador de red de Compute (roles/compute.networkAdmin).

Los administradores de servicios, que controlan el aprovisionamiento de los servicios de backend en un proyecto independiente, pueden colaborar con el administrador del balanceador de carga del proyecto frontend para invalidar la caché de sus servicios entre proyectos. En el caso de las reescrituras de URLs, asegúrese de que la invalidación coincida con el host y la ruta anteriores a la reescritura que envía el cliente.

Siguientes pasos