Exportar (0) Imprimir
Expandir todo

Expiración y expulsión (Caché en rol para Caché de Azure)

Actualizado: julio de 2010

noteNota
Si quiere que le guiemos a la hora de elegir la oferta de Caché de Azure que mejor se adapta a su aplicación, consulte ¿Cuál es la oferta de Caché de Azure más adecuada para mí?.

Caché de Microsoft Azure no conserva permanentemente en la memoria los objetos en caché. Además de quitarse explícitamente de la memoria caché con el método Remove, los objetos en caché también pueden expirar o el propio clúster de caché los puede expulsar.

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. El tiempo predeterminado varía si se utiliza almacenar en memoria caché en roles de o Shared Caching.

Cuando se utiliza almacenar en memoria caché basado en roles, existen tres opciones de expiración:

 

Tipo de caducidad Descripción

Ninguno

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.

Absoluto

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.

noteNota
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 Absoluto y no se puede establecer un tiempo de expiración predeterminado. Los elementos en 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 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 todo caso, cuando el tamaño de la caché supera los límites de su oferta de Shared Caching, se expulsan los elementos usados menos recientemente.

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é.

Hay dos tipos complementarios de invalidación de la memoria caché local: invalidación basada en tiempo de espera e invalidación basada en notificación.

TipSugerencia
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.

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.

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.

noteNota
No se admiten las notificaciones 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 obtener más información y ejemplos, vea Caché local (Caché en rol para Caché de Azure).

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 está determinado por dos factores: la cantidad de memoria física disponible en cada máquina y el porcentaje de almacenamiento en memoria caché reservado en cada máquina.

Cuando el consumo de memoria supera el umbral de memoria, los objetos se desalojan de la memoria, independientemente de si han expirado o no, hasta que se libera la presión de 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.

WarningAdvertencia
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 expulsión en una memoria caché.

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 se 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, invalidando los valores 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.

Vea también

Mostrar:
© 2014 Microsoft