Cette documentation est archivée et n’est pas conservée.

Expiration et éviction dans Azure In-Role Cache

Mis à jour: août 2015

ImportantImportant
Microsoft recommande que tous les nouveaux développements utilisent le Cache Redis Azure. Pour une documentation et des conseils actualisés sur le choix d'une offre de Cache Azure, voir Quelle est l'offre Azure Cache qui me convient ?

cache Microsoft Azure ne conserve pas les objets mis en cache dans la mémoire de façon permanente. Outre leur suppression explicite du cache à l'aide de la méthode Remove, les objets mis en cache peuvent également expirer ou être exclus par le cluster de cache.

L'expiration du cache permet au cluster de cache de supprimer automatiquement du cache des objets mis en cache. Lors de l'utilisation de la méthode Put ou Add, une valeur facultative de délai d'expiration de l'objet peut être définie pour un objet mis en cache spécifique, qui va déterminer sa durée de conservation dans le cache. Si la valeur du délai d'expiration de l'objet n'est pas fournie au moment de la mise en cache de celui-ci, l'objet mis en cache utilise le délai d'expiration par défaut.

Lorsque vous utilisez mise en cache basé sur les rôles, trois options d'expiration s'offrent à vous :

 

Type d'expiration Description

Aucune

L'expiration est désactivée. Les éléments restent dans le cache jusqu'à leur suppression ou jusqu'au redémarrage du cluster.

Absolu

Les éléments expirent après une durée spécifiée à partir de leur création.

Glissante

Les éléments expirent après une durée spécifiée à partir de leur dernier accès. À chaque accès de l'objet, la fenêtre de temps glissante est réinitialisée. Ainsi, les éléments fréquemment utilisés restent dans le cache plus longtemps.

noteRemarque
Il est important de noter le comportement de l'expiration Glissante lorsqu'elle est utilisée avec le cache local. Si un élément est lu dans le cache local, l'objet n'est pas accédé sur le cluster de cache. Il est donc possible que l'élément expire sur le serveur même s'il est lu en local.

Dans Shared Caching, l'expiration est toujours Absolu, et vous ne pouvez pas définir de délai d'expiration par défaut. Les éléments dans Shared Caching expirent au bout de 48 heures. Toutefois, les méthodes Put et Add permettent de définir des délais d'expiration explicites dans le code. Notez que les fournisseurs ASP.NET utilisent automatiquement ces surcharges pour fournir des délais d'expiration explicites pour l'état de session et la mise en cache de sortie. Dans tous les cas, lorsque la taille de votre cache dépasse la limite de votre offre Shared Caching, les éléments utilisés le plus récemment dans le cache sont exclus.

Lorsque les objets mis en cache sont verrouillés à des fins d'accès concurrentiel, ils ne sont pas supprimés du cache même s'ils ont dépassé leur délai d'expiration. Si celui-ci est effectivement dépassé, dès leur déverrouillage, ils sont immédiatement supprimés du cache.

Pour éviter cette suppression instantanée lors du déverrouillage des objets expirés, la méthode Unlock prend également en charge l'extension du délai d'expiration de l'objet mis en cache.

Il existe deux types complémentaires d'invalidation pour le cache local : invalidation basée sur un délai d'expiration et invalidation basée sur une notification.

TipConseil
Une fois les objets stockés dans le cache local, votre application peut les utiliser jusqu'à leur invalidation, qu'ils soient mis à jour par un autre client sur le cluster de cache ou non. Pour cette raison, il est recommandé d'activer le cache local pour les données qui sont rarement modifiées.

Une fois les objets téléchargés vers le cache local, ils y restent jusqu'à atteindre la valeur de délai d'expiration spécifiée dans les paramètres de configuration du client de cache. Une fois que les objets ont atteint la valeur de délai d'expiration, ils sont invalidés de sorte que chaque objet peut être actualisé à partir du cluster de cache la prochaine fois qu'il est demandé.

Si le cache local de votre client de cache est activé, vous pouvez également utiliser les notifications de cache pour invalider automatiquement les objets mis en cache localement. En réduisant la durée de vie de ces objets selon vos besoins, vous pouvez réduire les risques que votre application utilise des données obsolètes.

noteRemarque
Les notifications ne sont pas prises en charge dans la Shared Caching.

Lorsque vous utilisez les notifications de cache, votre application interroge régulièrement le cluster de cache pour vérifier si de nouvelles notifications sont disponibles. Par défaut, cette fréquence d'interrogation est de 300 secondes. Elle est spécifiée en unités de secondes dans les paramètres de configuration de l'application. Remarquez que même avec une invalidation basée sur une notification, les délais d'expiration s'appliquent aux éléments du cache local. L'invalidation basée sur une notification est donc complémentaire de l'invalidation basée sur un délai d'expiration.

Pour plus d'informations et accéder à des exemples, voir Cache local dans Azure In-Role Cache.

Pour que la capacité mémoire soit disponible pour le cache sur chaque hôte de cache, l'éviction LRU (dernier récemment utilisé) est prise en charge. Les limites permettent de s'assurer que la mémoire est répartie de manière égale dans tous les hôtes de cache du cluster. Deux facteurs déterminent ces limites : la quantité de mémoire physique disponible sur chaque ordinateur et le pourcentage de mémoire cache réservée sur chaque ordinateur.

Lorsque la consommation de mémoire dépasse le seuil de la mémoire, les objets sont supprimés de la mémoire, qu'ils aient expiré ou non, jusqu'à ce que la pression exercée sur la mémoire diminue. Par la suite, les objets mis en cache peuvent être réacheminés vers d'autres ordinateurs du cluster de cache pour conserver une répartition optimale de la mémoire.

WarningAvertissement
Si vous désactivez l'éviction, vous courrez le risque de limiter la bande passante. Dans ce cas, la mémoire a dépassé la limite, mais il n'y a aucun moyen de pallier au manque de mémoire. Les clients qui tentent d'ajouter des éléments au cache dans cet état reçoivent une exception jusqu'à ce que le problème soit résolu. Notez que Shared Caching ne prend pas en charge la désactivation de l'éviction sur un cache.

Les comportements d'expiration et d'éviction sont configurés au niveau du cache nommé dans les paramètres de configuration du cluster.

Les méthodes suivantes permettent de remplacer les paramètres par défaut du cache :

  • Les méthodes Add et Put fournissent des surcharges qui permettent de spécifier une valeur de délai d'expiration uniquement pour l'objet ajouté au cache.

  • Les méthodes PutAndUnlock et Unlock fournissent des surcharges qui permettent de prolonger le délai d'expiration d'un objet après son déverrouillage.

  • La méthode ResetObjectTimeout permet de prolonger explicitement la durée de vie d'un objet, en remplaçant les paramètres d'expiration du cache.

Indépendamment des paramètres d'expiration ou d'éviction, si un cluster de cache est redémarré, tous les objets du cache sont effacés. Si les données sont introuvables dans le cache, le code de votre application doit recharger celui-ci à partir d'une source de données. Cette opération est généralement appelée « mode de programmation de type cache-aside ».

Voir aussi

Afficher: