Expiración y expulsión en Caché en rol de Azure
Importante
Microsoft recomienda todos los nuevos desarrollos que usen Azure Redis Cache. Para obtener documentación actual e instrucciones sobre cómo elegir una oferta de Azure Cache, consulte ¿Qué oferta de Azure Cache es adecuada para mí?
Microsoft Azure Caché no conserva los objetos almacenados en caché de forma permanente. Además de quitarse explícitamente de la memoria caché mediante el uso del método Remove , los objetos almacenados en caché también pueden expirar o ser expulsados por el clúster de caché.
Expiration
La expiración de caché permite al clúster de caché quitar automáticamente los objetos almacenados en caché. Cuando se usan los métodos Put o Add, se puede establecer un valor opcional de expiración de objeto, para cada objeto en caché, que determinará durante cuánto tiempo permanecerá en caché. Si el valor de tiempo de espera del objeto no se proporciona en el momento en que el objeto se almacena en caché, este usa el tiempo de expiración predeterminado.
Al usar el almacenamiento en caché basado en roles, tiene tres opciones para la expiración:
| Tipo de caducidad | Descripción |
|---|---|
None |
La expiración está deshabilitada. Los elementos permanecen en la memoria caché hasta que se expulsan o hasta que el clúster de caché se reinicia. |
Absolute |
Una vez que el período de tiempo especificado ha transcurrido, el elemento expira. |
Deslizante |
Los elementos expiran cuando ha transcurrido el período de tiempo especificado desde la última vez que se accedió al elemento. La ventana de tiempo deslizante se restablece cada vez que se accede a un objeto. De este modo, los elementos que se usan con frecuencia se conservan en la memoria caché durante más tiempo. |
Nota
Es importante tener en cuenta el comportamiento de la expiración Deslizante cuando se usa en combinación con caché local. Si un elemento se lee desde la memoria caché local, esta no accede al objeto en el clúster de caché. Por lo tanto, es posible que el elemento expire en el servidor, incluso si se está leyendo de forma local.
En Shared Caching, la expiración siempre es Absoluta y no hay ninguna manera de establecer una hora de expiración predeterminada. Los elementos de Shared Caching expiran después de 48 horas. Sin embargo, puede usar los métodos Put y Add para establecer tiempos de expiración explícitos en el código. Tenga en cuenta que los proveedores de ASP.NET utilizan automáticamente estas sobrecargas para proporcionar tiempos de espera explícitos por estado de sesión y almacenamiento en caché de resultados. En cualquier caso, cuando el tamaño de la memoria caché supera los límites de la oferta de Shared Caching, se expulsan los elementos usados menos recientemente en la memoria caché.
Cuando los objetos en caché se bloquean con fines de concurrencia, no se eliminan de la memoria caché aunque hayan expirado. Cuando se desbloqueen, se quitan inmediatamente de la memoria caché si han expirado.
Para evitar la eliminación instantánea cuando se desbloquean objetos caducados, el método Unlock también permite extender la expiración del objeto en caché.
Invalidación de la memoria caché local
Hay dos tipos complementarios de invalidación para la caché local: invalidación basada en el tiempo de espera y invalidación basada en notificaciones.
Sugerencia
Una vez que se han almacenado los objetos en la memoria caché local, la aplicación puede seguir usando estos objetos hasta que se invaliden, independientemente de si otro cliente los ha actualizado o no en el clúster de caché. Por esta razón, es mejor habilitar la memoria caché local para datos que no se modifican con frecuencia.
Invalidación basada en tiempo de espera
Una vez que los objetos se han descargado a la memoria caché local, permanecen allí hasta que alcanzan el valor de tiempo de espera de objeto especificado en los valores de configuración del cliente de caché. Cuando alcanzan este valor de tiempo de espera, los objetos se invalidan, de modo que pueden actualizarse desde el clúster de caché la próxima vez que se solicite.
Invalidación basada en notificación
Si el cliente de caché ha habilitado la memoria caché local, también se pueden usar notificaciones de caché para invalidar automáticamente los objetos almacenados en caché local. Al reducir la vida útil de estos objetos según las necesidades, se puede reducir la posibilidad de que la aplicación use datos obsoletos.
Nota
Las notificaciones no se admiten en Shared Caching.
Cuando se usan notificaciones de caché, la aplicación comprueba con el clúster de caché, a intervalos periódicos, si hay nuevas notificaciones disponibles. Este intervalo, denominado intervalo de sondeo, se produce cada 300 segundos de forma predeterminada. El intervalo de sondeo se especifica en unidades de segundos en las opciones de configuración de la aplicación. Tenga en cuenta que, con la invalidación basada en notificación, se siguen aplicando tiempos de espera a los elementos de la memoria caché local. De ese modo, la invalidación basada en notificación es complementaria a la invalidación basada en tiempo de espera.
Para más información y ejemplos, consulte Caché local en Azure In-Role Cache.
Expulsión
Para mantener la capacidad de memoria disponible para la memoria caché en cada host de caché, se admite la expulsión basada en LRU (menos usado recientemente). Los umbrales se usan para asegurar que la memoria se distribuye de manera uniforme entre todos los hosts de caché en el clúster. Este umbral viene determinado por dos factores: la cantidad de memoria física disponible en cada máquina y el porcentaje de memoria reservada en caché en cada máquina.
Cuando el consumo de memoria supera un cierto umbral, se eliminan objetos almacenados, independientemente de si están caducados o no, hasta que se alivia la carga de la memoria. En consecuencia, es posible que los objetos almacenados en caché se redistribuyan a otras máquinas en el clúster de caché para mantener una distribución óptima de memoria.
Advertencia
Si deshabilita la expulsión, corre el riesgo de que se produzcan limitaciones. En esta condición, la memoria ha superado el umbral, pero no hay posibilidad de subsanar la escasez en memoria. Los clientes que intenten agregar elementos a la memoria caché en este estado recibirán una excepción hasta que se resuelva. Tenga en cuenta que Shared Caching no admite la deshabilitación de la expulsión en una memoria caché.
Especificar la configuración de la expiración y expulsión
Los comportamientos de expiración y expulsión se configuran en el nivel de caché con nombre en los ajustes de configuración de clúster.
Los métodos siguientes permiten invalidar los ajustes predeterminados de la memoria caché:
Los métodos Add y Put proporcionan sobrecargas que permiten especificar un valor de tiempo de espera de expiración solo para el objeto que agrega a la memoria caché.
Los métodos PutAndUnlock y Unlock proporcionan sobrecargas que permiten extender la expiración de un objeto después de desbloquearlo.
El método ResetObjectTimeout permite extender explícitamente la duración de un objeto, reemplazando la configuración de expiración de la memoria caché.
Independientemente de la configuración de expiración y expulsión, los objetos de la caché se borran si un clúster de caché se reinicia. El código de aplicación debe recargar la memoria caché a partir del origen de datos si los datos no se encuentran en la memoria caché. Esto se denomina frecuentemente modelo de programación cache-aside.