Expiration et éviction dans Azure In-Role Cache
Important
Microsoft recommande tous les nouveaux développements à l’aide du Cache Redis Azure. Pour obtenir de la documentation et des conseils actuels sur le choix d’une offre Azure Cache, consultez Quelle offre Azure Cache est adaptée à moi ?
Microsoft Azure Cache ne conserve pas les objets mis en cache en mémoire définitivement. En plus d’être explicitement supprimés du cache à l’aide de la méthode Remove , les objets mis en cache peuvent également expirer ou être supprimés par le cluster de cache.
Expiration
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 la mise en cache basée sur le rôle, vous avez trois options pour l’expiration :
| Type d'expiration | Description |
|---|---|
Aucun |
L'expiration est désactivée. Les éléments restent dans le cache jusqu'à leur suppression ou jusqu'au redémarrage du cluster. |
Absolute |
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. |
Notes
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 absolue et il n’existe aucun moyen de définir une heure d’expiration par défaut. Les éléments de Shared Caching expirent après 48 heures. Toutefois, vous pouvez utiliser les méthodes Put et Add pour définir des heures 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 les deux cas, lorsque votre taille de cache dépasse les limites de votre offre de Shared Caching, les éléments les moins récemment utilisés dans le cache sont supprimés.
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.
Invalidation du cache local
Il existe deux types complémentaires d’invalidation pour le cache local : une invalidation basée sur le délai d’attente et une invalidation basée sur des notifications.
Conseil
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.
Invalidation basée sur un délai d'expiration
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é.
Invalidation basée sur une notification
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.
Notes
Les notifications ne sont pas prises en charge dans 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 d’exemples, consultez Cache local dans Azure In-Role Cache.
Expulsion
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. Ce seuil est déterminé par deux facteurs : la quantité de mémoire physique disponible sur chaque ordinateur et le pourcentage de mémoire de mise en cache réservée sur chaque ordinateur.
Lorsque la consommation de mémoire dépasse le seuil de mémoire, les objets sont expulsés de la mémoire, qu'ils aient expiré ou pas, jusqu'à ce que la pression sur la mémoire se relâche. 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.
Avertissement
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.
Spécification des paramètres d'expiration et d'éviction
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 and Put fournissent des surcharges qui vous permettent de spécifier une valeur de délai d’expiration uniquement pour l’objet que vous ajoutez au cache.
Les méthodes PutAndUnlock et Unlock fournissent des surcharges qui vous permettent d’étendre l’expiration d’un objet après le déverrouillage.
La méthode ResetObjectTimeout vous permet d’étendre 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 ».