Modèle Cache-Aside

Azure Redis géré

Ce modèle charge les données à la demande dans un cache à partir d’un magasin de données. Utilisez ce modèle pour améliorer les performances et aider à maintenir la cohérence entre les données d’un cache et des données dans un magasin de données sous-jacent.

Contexte et problème

Les applications utilisent un cache pour améliorer les performances pour un accès répété aux informations dans un magasin de données. Toutefois, les données mises en cache ne peuvent pas toujours rester cohérentes avec le magasin de données. Les applications doivent implémenter une stratégie qui conserve les données dans le cache aussi up-to-date que possible. La stratégie doit également détecter quand les données mises en cache sont obsolètes et les gérer de manière appropriée.

Solution

De nombreux systèmes de mise en cache commerciaux fournissent des opérations de lecture et d’écriture directe ou en écriture différée. Dans ces systèmes, une application récupère des données en établissant une référence au cache. Si les données ne se trouvent pas dans le cache, l’application la récupère à partir du magasin de données et l’ajoute au cache. Le système écrit automatiquement les modifications apportées aux données mises en cache dans le magasin de données.

Pour les caches qui ne fournissent pas cette fonctionnalité, les applications qui utilisent le cache doivent conserver les données.

Une application peut émuler la fonctionnalité de mise en cache en lecture en implémentant le modèle Cache-Aside. Cette stratégie charge des données dans le cache à la demande. Le diagramme suivant utilise le modèle Cache-Aside pour stocker des données dans le cache.

Le diagramme comprend une application, un cache et un magasin de données. Le cache pointe vers l’application, identifiée comme étape 1. Le magasin de données pointe vers l’application, indiquée comme l’étape 2. L’application pointe le cache portant l’étiquette étape 3.

1. L’application détermine si un élément réside actuellement dans le cache en tentant de lire à partir du cache.

2. Si l’élément n’est pas dans le cache, également appelé absence de cache, l’application récupère l’élément à partir du magasin de données.

3. L’application ajoute l’élément au cache, puis le retourne à l’appelant.

Si une application met à jour les informations, elle peut suivre la stratégie d’écriture directe en modifiant le magasin de données et en invalidant l’élément correspondant dans le cache.

Lorsque l’élément est de nouveau nécessaire, le modèle Cache-Aside récupère les données mises à jour à partir du magasin de données et l’ajoute au cache.

Problèmes et considérations

Tenez compte des points suivants lorsque vous décidez comment implémenter ce modèle :

• Durée de vie des données mises en cache : De nombreux caches utilisent une stratégie d’expiration pour invalider les données et les supprimer du cache si elles ne sont pas accessibles pendant une période définie. Pour rendre le cache-aside efficace, assurez-vous que la stratégie d'expiration correspond au modèle d'accès des applications qui utilisent les données. Ne définissez pas la période d'expiration trop courte, car une expiration prématurée peut entraîner la récupération continue des données à partir de la source de données et de l’ajouter au cache. De même, ne faites pas la période d'expiration si longue que les données mises en cache deviennent obsolètes. La mise en cache fonctionne mieux pour les données ou données relativement statiques que les applications lisent fréquemment.

• Supprimer les données : La plupart des caches ont une taille limitée par rapport au magasin de données où les données proviennent. Si le cache dépasse sa limite de taille, il supprime les données. La plupart des caches adoptent une stratégie moins récemment utilisée pour sélectionner des éléments pour l’éviction, mais certaines autorisent la personnalisation.

• Configuration: Vous pouvez configurer le comportement du cache globalement ou par élément mis en cache. Une seule stratégie d’éviction globale peut ne pas convenir à tous les éléments. Si un élément est coûteux à récupérer, configurez l’élément de cache individuellement. Dans ce cas, il est judicieux de conserver l’élément dans le cache, même s’il est accessible moins fréquemment que les articles moins chers.

• Priming the cache : De nombreuses solutions préremplient le cache avec des données dont une application a probablement besoin dans le cadre du traitement de démarrage. Le modèle Cache-Aside reste utile lorsque certaines de ces données expirent ou sont supprimées.

• Cohérence: Le modèle Cache-Aside ne garantit pas la cohérence entre le magasin de données et le cache. Par exemple, un processus externe peut modifier un élément dans le magasin de données à tout moment. Cette modification n’apparaît pas dans le cache tant que l’élément ne se charge pas à nouveau. Dans un système qui réplique les données entre les magasins de données, la synchronisation fréquente peut compliquer la cohérence.

• Mise en cache locale : Un cache peut être local dans une instance d’application et être stocké en mémoire. Le cache-aside fonctionne bien dans cet environnement si une application accède à plusieurs reprises aux mêmes données. Toutefois, un cache local est privé, de sorte que différentes instances d’application peuvent chacune avoir une copie des mêmes données mises en cache. Ces données peuvent rapidement devenir incohérentes entre les caches. Vous devrez peut-être expirer des données dans un cache privé et l’actualiser plus fréquemment. Dans ces scénarios, envisagez d’utiliser un mécanisme de mise en cache partagé ou distribué.

• Mise en cache sémantique : Certaines charges de travail peuvent tirer parti de la récupération du cache en fonction de la signification sémantique plutôt que des clés exactes. Cette approche réduit le nombre de requêtes et de jetons envoyés aux modèles de langage. Utilisez uniquement la mise en cache sémantique lorsque les données prennent en charge l’équivalence sémantique, ne risque pas de retourner des réponses non liées et ne contiennent pas de données privées et sensibles. Par exemple, « Quel est mon salaire net annuel ? » est sémantiquement similaire à « Quel est mon salaire net annuel ? » Mais si différents utilisateurs posent ces questions, les réponses devraient être différentes. Vous ne devez pas non plus inclure ces données sensibles dans votre cache.

Quand utiliser ce modèle

Utilisez ce modèle dans les situations suivantes :

• Un cache ne fournit pas d’opérations de double lecture et de double écriture natives.

• La demande en ressources n’est pas prévisible. Ce modèle permet aux applications de charger des données à la demande. Elle ne suppose pas les données dont une application a besoin à l’avance.

Ce modèle peut ne pas convenir lorsque :

• Les données sont sensibles ou liées à la sécurité. Le stockage de données dans un cache peut être inapproprié, en particulier lorsque plusieurs applications ou utilisateurs partagent le cache. Récupérez toujours ce type de données à partir de la source primaire.

• Le jeu de données mis en cache est statique. Si les données s’intègrent dans l’espace de cache disponible, primez le cache avec les données au démarrage et appliquez une stratégie qui empêche l’expiration des données.

• La plupart des requêtes ne rencontrent pas d’accès au cache. Dans ce cas, la surcharge liée à la vérification du cache et au chargement des données peut dépasser les avantages de la mise en cache.

• Vous cachez les informations d’état de session dans une application web hébergée dans une batterie de serveurs web. Dans cet environnement, évitez d’introduire des dépendances basées sur l’affinité client-serveur.

Conception de la charge de travail

Évaluez comment utiliser le modèle Cache-Aside dans la conception d’une charge de travail pour répondre aux objectifs et principes abordés dans les piliers Azure Well-Architected Framework. Le tableau suivant fournit des conseils sur la façon dont ce modèle prend en charge les objectifs de chaque pilier.

Pilier	Comment ce modèle soutient les objectifs des piliers.
Les décisions de conception de fiabilité aident votre charge de travail à devenir résiliente au dysfonctionnement et à s’assurer qu’elle se rétablit dans un état entièrement opérationnel après une défaillance.	La mise en cache réplique les données. De manière limitée, elle peut conserver la disponibilité des données fréquemment sollicitées si le magasin de données d’origine devient temporairement indisponible. Si le cache ne fonctionne pas, la charge de travail peut revenir au magasin de données d’origine. - RE :05 Redondance
L’efficacité des performances permet à votre charge de travail de répondre efficacement aux demandes par le biais d’optimisations de la mise à l’échelle, des données et du code.	La mise en cache améliore les performances des données lourdes en lecture qui changent rarement et tolère une certaine obsolescence. - PE :08 Performance des données - PE :12 Optimisation continue des performances

Si ce modèle introduit des compromis au sein d’un pilier, considérez-les contre les objectifs des autres piliers.

Exemple

Envisagez d’utiliser Azure Managed Redis pour créer un cache distribué que plusieurs instances d’application peuvent partager.

L’exemple suivant utilise le client StackExchange.Redis , qui est une bibliothèque de client Redis écrite pour .NET. Pour vous connecter à une instance Redis managée Azure, appelez la méthode statique ConnectionMultiplexer.Connect et passez la chaîne de connexion. La méthode renvoie un élément ConnectionMultiplexer qui représente la connexion.

Une façon de partager une ConnectionMultiplexer instance dans votre application consiste à avoir une propriété statique qui retourne une instance connectée, similaire à l’exemple suivant. Cette approche fournit une méthode thread-safe permettant d’initialiser une seule instance connectée.

private static ConnectionMultiplexer Connection;

// Redis connection string information
private static Lazy<ConnectionMultiplexer> lazyConnection = new Lazy<ConnectionMultiplexer>(() =>
{
    string cacheConnection = ConfigurationManager.AppSettings["CacheConnection"].ToString();
    return ConnectionMultiplexer.Connect(cacheConnection);
});

public static ConnectionMultiplexer Connection => lazyConnection.Value;

La GetMyEntityAsync méthode de l’exemple suivant montre une implémentation du modèle Cache-Aside. Cette méthode récupère un objet à partir du cache en utilisant l'approche "read-through".

La méthode identifie un objet à l’aide d’un ID entier comme clé. Il tente de récupérer un élément du cache à l’aide de cette clé. Si le cache contient un élément correspondant, il retourne l’élément. Si le cache ne contient pas de correspondance, la GetMyEntityAsync méthode récupère l’objet à partir d’un magasin de données, l’ajoute au cache, puis le retourne. Cet exemple omet le code qui lit les données du magasin de données, car cette logique dépend du magasin de données. L’élément mis en cache est configuré pour l’empêcher de devenir obsolète si un autre service ou processus le met à jour.

// Set five minute expiration as a default
private const double DefaultExpirationTimeInMinutes = 5.0;

public async Task<MyEntity> GetMyEntityAsync(int id)
{
  // Define a unique key for this method and its parameters.
  var key = $"MyEntity:{id}";
  var cache = Connection.GetDatabase();

  // Try to get the entity from the cache.
  var json = await cache.StringGetAsync(key).ConfigureAwait(false);
  var value = string.IsNullOrWhiteSpace(json)
                ? default(MyEntity)
                : JsonConvert.DeserializeObject<MyEntity>(json);

  if (value == null) // Cache miss
  {
    // If there's a cache miss, get the entity from the original store and cache it.
    // Code has been omitted because it is data store dependent.
    value = ...;

    // Avoid caching a null value.
    if (value != null)
    {
      // Put the item in the cache with a custom expiration time that
      // depends on how critical it is to have stale data.
      await cache.StringSetAsync(key, JsonConvert.SerializeObject(value)).ConfigureAwait(false);
      await cache.KeyExpireAsync(key, TimeSpan.FromMinutes(DefaultExpirationTimeInMinutes)).ConfigureAwait(false);
    }
  }

  return value;
}

Note

Les exemples utilisent Azure Managed Redis pour accéder au magasin et récupérer des informations à partir du cache. Pour plus d’informations, consultez Créer une instance Azure Managed Redis et utiliser Azure Managed Redis dans .NET Core.

La méthode suivante UpdateEntityAsync montre comment invalider un objet dans le cache lorsque l’application modifie la valeur. Le code met à jour la banque de données d’origine, puis supprime l’élément en cache du cache.

public async Task UpdateEntityAsync(MyEntity entity)
{
    // Update the object in the original data store.
    await this.store.UpdateEntityAsync(entity).ConfigureAwait(false);

    // Invalidate the current cache object.
    var cache = Connection.GetDatabase();
    var id = entity.Id;
    var key = $"MyEntity:{id}"; // The key for the cached object.
    await cache.KeyDeleteAsync(key).ConfigureAwait(false); // Delete this key from the cache.
}

Note

L’ordre dans lequel sont effectuées les étapes est important. Mettez à jour la banque de données avant de supprimer l’élément du cache. Si vous supprimez d’abord l’élément mis en cache, il existe une petite fenêtre de temps quand un client peut extraire l’élément avant la mise à jour du magasin de données. Dans ce cas, la récupération entraîne un échec de cache, car l’élément n’est pas dans le cache. Un défaut de cache fait que l'application doive récupérer l'élément obsolète à partir du magasin de données et le réintégrer dans le cache. Cette séquence entraîne des données obsolètes dans le cache.

Étapes suivantes

• Aperçu de la cohérence des données : cet aperçu décrit les problèmes de cohérence dans les données distribuées. Il résume également la façon dont une application peut implémenter une cohérence éventuelle pour maintenir la disponibilité des données. Les applications cloud stockent généralement des données dans plusieurs magasins de données et emplacements. Vous devez gérer et maintenir efficacement la cohérence des données dans cet environnement, en particulier en raison de problèmes de concurrence et de disponibilité qui peuvent survenir.

• Utilisez Azure Managed Redis comme cache sémantique : ce tutoriel vous montre comment implémenter la mise en cache sémantique à l’aide d’Azure Managed Redis.

Ressources associées

• Modèle d’application web fiable : ce modèle applique le modèle Cache-Aside aux applications web dans le cloud.

• Conseils de mise en cache : ces conseils fournissent plus d’informations sur la façon de mettre en cache des données dans une solution cloud et des problèmes à prendre en compte lorsque vous implémentez un cache.

Ce modèle charge les données à la demande dans un cache à partir d’un magasin de données. Utilisez ce modèle pour améliorer les performances et aider à maintenir la cohérence entre les données d’un cache et des données dans un magasin de données sous-jacent.

Contexte et problème

Les applications utilisent un cache pour améliorer les performances pour un accès répété aux informations dans un magasin de données. Toutefois, les données mises en cache ne peuvent pas toujours rester cohérentes avec le magasin de données. Les applications doivent implémenter une stratégie qui conserve les données dans le cache aussi up-to-date que possible. La stratégie doit également détecter quand les données mises en cache sont obsolètes et les gérer de manière appropriée.

Solution

De nombreux systèmes de mise en cache commerciaux fournissent des opérations de lecture et d’écriture directe ou en écriture différée. Dans ces systèmes, une application récupère des données en établissant une référence au cache. Si les données ne se trouvent pas dans le cache, l’application la récupère à partir du magasin de données et l’ajoute au cache. Le système écrit automatiquement les modifications apportées aux données mises en cache dans le magasin de données.

Pour les caches qui ne fournissent pas cette fonctionnalité, les applications qui utilisent le cache doivent conserver les données.

Une application peut émuler la fonctionnalité de mise en cache en lecture en implémentant le modèle Cache-Aside. Cette stratégie charge des données dans le cache à la demande. Le diagramme suivant utilise le modèle Cache-Aside pour stocker des données dans le cache.

Le diagramme comprend une application, un cache et un magasin de données. Le cache pointe vers l’application, identifiée comme étape 1. Le magasin de données pointe vers l’application, indiquée comme l’étape 2. L’application pointe le cache portant l’étiquette étape 3.

1. L’application détermine si un élément réside actuellement dans le cache en tentant de lire à partir du cache.

2. Si l’élément n’est pas dans le cache, également appelé absence de cache, l’application récupère l’élément à partir du magasin de données.

3. L’application ajoute l’élément au cache, puis le retourne à l’appelant.

Si une application met à jour les informations, elle peut suivre la stratégie d’écriture directe en modifiant le magasin de données et en invalidant l’élément correspondant dans le cache.

Lorsque l’élément est de nouveau nécessaire, le modèle Cache-Aside récupère les données mises à jour à partir du magasin de données et l’ajoute au cache.

Problèmes et considérations

Tenez compte des points suivants lorsque vous décidez comment implémenter ce modèle :

• Durée de vie des données mises en cache : De nombreux caches utilisent une stratégie d’expiration pour invalider les données et les supprimer du cache si elles ne sont pas accessibles pendant une période définie. Pour rendre le cache-aside efficace, assurez-vous que la stratégie d'expiration correspond au modèle d'accès des applications qui utilisent les données. Ne définissez pas la période d'expiration trop courte, car une expiration prématurée peut entraîner la récupération continue des données à partir de la source de données et de l’ajouter au cache. De même, ne faites pas la période d'expiration si longue que les données mises en cache deviennent obsolètes. La mise en cache fonctionne mieux pour les données ou données relativement statiques que les applications lisent fréquemment.

• Supprimer les données : La plupart des caches ont une taille limitée par rapport au magasin de données où les données proviennent. Si le cache dépasse sa limite de taille, il supprime les données. La plupart des caches adoptent une stratégie moins récemment utilisée pour sélectionner des éléments pour l’éviction, mais certaines autorisent la personnalisation.

• Configuration: Vous pouvez configurer le comportement du cache globalement ou par élément mis en cache. Une seule stratégie d’éviction globale peut ne pas convenir à tous les éléments. Si un élément est coûteux à récupérer, configurez l’élément de cache individuellement. Dans ce cas, il est judicieux de conserver l’élément dans le cache, même s’il est accessible moins fréquemment que les articles moins chers.

• Priming the cache : De nombreuses solutions préremplient le cache avec des données dont une application a probablement besoin dans le cadre du traitement de démarrage. Le modèle Cache-Aside reste utile lorsque certaines de ces données expirent ou sont supprimées.

• Cohérence: Le modèle Cache-Aside ne garantit pas la cohérence entre le magasin de données et le cache. Par exemple, un processus externe peut modifier un élément dans le magasin de données à tout moment. Cette modification n’apparaît pas dans le cache tant que l’élément ne se charge pas à nouveau. Dans un système qui réplique les données entre les magasins de données, la synchronisation fréquente peut compliquer la cohérence.

• Mise en cache locale : Un cache peut être local dans une instance d’application et être stocké en mémoire. Le cache-aside fonctionne bien dans cet environnement si une application accède à plusieurs reprises aux mêmes données. Toutefois, un cache local est privé, de sorte que différentes instances d’application peuvent chacune avoir une copie des mêmes données mises en cache. Ces données peuvent rapidement devenir incohérentes entre les caches. Vous devrez peut-être expirer des données dans un cache privé et l’actualiser plus fréquemment. Dans ces scénarios, envisagez d’utiliser un mécanisme de mise en cache partagé ou distribué.

• Mise en cache sémantique : Certaines charges de travail peuvent tirer parti de la récupération du cache en fonction de la signification sémantique plutôt que des clés exactes. Cette approche réduit le nombre de requêtes et de jetons envoyés aux modèles de langage. Utilisez uniquement la mise en cache sémantique lorsque les données prennent en charge l’équivalence sémantique, ne risque pas de retourner des réponses non liées et ne contiennent pas de données privées et sensibles. Par exemple, « Quel est mon salaire net annuel ? » est sémantiquement similaire à « Quel est mon salaire net annuel ? » Mais si différents utilisateurs posent ces questions, les réponses devraient être différentes. Vous ne devez pas non plus inclure ces données sensibles dans votre cache.

Quand utiliser ce modèle

Utilisez ce modèle dans les situations suivantes :

• Un cache ne fournit pas d’opérations de double lecture et de double écriture natives.

• La demande en ressources n’est pas prévisible. Ce modèle permet aux applications de charger des données à la demande. Elle ne suppose pas les données dont une application a besoin à l’avance.

Ce modèle peut ne pas convenir lorsque :

• Les données sont sensibles ou liées à la sécurité. Le stockage de données dans un cache peut être inapproprié, en particulier lorsque plusieurs applications ou utilisateurs partagent le cache. Récupérez toujours ce type de données à partir de la source primaire.

• Le jeu de données mis en cache est statique. Si les données s’intègrent dans l’espace de cache disponible, primez le cache avec les données au démarrage et appliquez une stratégie qui empêche l’expiration des données.

• La plupart des requêtes ne rencontrent pas d’accès au cache. Dans ce cas, la surcharge liée à la vérification du cache et au chargement des données peut dépasser les avantages de la mise en cache.

• Vous cachez les informations d’état de session dans une application web hébergée dans une batterie de serveurs web. Dans cet environnement, évitez d’introduire des dépendances basées sur l’affinité client-serveur.

Conception de la charge de travail

Évaluez comment utiliser le modèle Cache-Aside dans la conception d’une charge de travail pour répondre aux objectifs et principes abordés dans les piliers Azure Well-Architected Framework. Le tableau suivant fournit des conseils sur la façon dont ce modèle prend en charge les objectifs de chaque pilier.

Pilier	Comment ce modèle soutient les objectifs des piliers.
Les décisions de conception de fiabilité aident votre charge de travail à devenir résiliente au dysfonctionnement et à s’assurer qu’elle se rétablit dans un état entièrement opérationnel après une défaillance.	La mise en cache réplique les données. De manière limitée, elle peut conserver la disponibilité des données fréquemment sollicitées si le magasin de données d’origine devient temporairement indisponible. Si le cache ne fonctionne pas, la charge de travail peut revenir au magasin de données d’origine. - RE :05 Redondance
L’efficacité des performances permet à votre charge de travail de répondre efficacement aux demandes par le biais d’optimisations de la mise à l’échelle, des données et du code.	La mise en cache améliore les performances des données lourdes en lecture qui changent rarement et tolère une certaine obsolescence. - PE :08 Performance des données - PE :12 Optimisation continue des performances

Si ce modèle introduit des compromis au sein d’un pilier, considérez-les contre les objectifs des autres piliers.

Exemple

Envisagez d’utiliser Azure Managed Redis pour créer un cache distribué que plusieurs instances d’application peuvent partager.

L’exemple suivant utilise le client StackExchange.Redis , qui est une bibliothèque de client Redis écrite pour .NET. Pour vous connecter à une instance Redis managée Azure, appelez la méthode statique ConnectionMultiplexer.Connect et passez la chaîne de connexion. La méthode renvoie un élément ConnectionMultiplexer qui représente la connexion.

Une façon de partager une ConnectionMultiplexer instance dans votre application consiste à avoir une propriété statique qui retourne une instance connectée, similaire à l’exemple suivant. Cette approche fournit une méthode thread-safe permettant d’initialiser une seule instance connectée.

private static ConnectionMultiplexer Connection;

// Redis connection string information
private static Lazy<ConnectionMultiplexer> lazyConnection = new Lazy<ConnectionMultiplexer>(() =>
{
    string cacheConnection = ConfigurationManager.AppSettings["CacheConnection"].ToString();
    return ConnectionMultiplexer.Connect(cacheConnection);
});

public static ConnectionMultiplexer Connection => lazyConnection.Value;

La GetMyEntityAsync méthode de l’exemple suivant montre une implémentation du modèle Cache-Aside. Cette méthode récupère un objet à partir du cache en utilisant l'approche "read-through".

La méthode identifie un objet à l’aide d’un ID entier comme clé. Il tente de récupérer un élément du cache à l’aide de cette clé. Si le cache contient un élément correspondant, il retourne l’élément. Si le cache ne contient pas de correspondance, la GetMyEntityAsync méthode récupère l’objet à partir d’un magasin de données, l’ajoute au cache, puis le retourne. Cet exemple omet le code qui lit les données du magasin de données, car cette logique dépend du magasin de données. L’élément mis en cache est configuré pour l’empêcher de devenir obsolète si un autre service ou processus le met à jour.

// Set five minute expiration as a default
private const double DefaultExpirationTimeInMinutes = 5.0;

public async Task<MyEntity> GetMyEntityAsync(int id)
{
  // Define a unique key for this method and its parameters.
  var key = $"MyEntity:{id}";
  var cache = Connection.GetDatabase();

  // Try to get the entity from the cache.
  var json = await cache.StringGetAsync(key).ConfigureAwait(false);
  var value = string.IsNullOrWhiteSpace(json)
                ? default(MyEntity)
                : JsonConvert.DeserializeObject<MyEntity>(json);

  if (value == null) // Cache miss
  {
    // If there's a cache miss, get the entity from the original store and cache it.
    // Code has been omitted because it is data store dependent.
    value = ...;

    // Avoid caching a null value.
    if (value != null)
    {
      // Put the item in the cache with a custom expiration time that
      // depends on how critical it is to have stale data.
      await cache.StringSetAsync(key, JsonConvert.SerializeObject(value)).ConfigureAwait(false);
      await cache.KeyExpireAsync(key, TimeSpan.FromMinutes(DefaultExpirationTimeInMinutes)).ConfigureAwait(false);
    }
  }

  return value;
}

Note

Les exemples utilisent Azure Managed Redis pour accéder au magasin et récupérer des informations à partir du cache. Pour plus d’informations, consultez Créer une instance Azure Managed Redis et utiliser Azure Managed Redis dans .NET Core.

La méthode suivante UpdateEntityAsync montre comment invalider un objet dans le cache lorsque l’application modifie la valeur. Le code met à jour la banque de données d’origine, puis supprime l’élément en cache du cache.

public async Task UpdateEntityAsync(MyEntity entity)
{
    // Update the object in the original data store.
    await this.store.UpdateEntityAsync(entity).ConfigureAwait(false);

    // Invalidate the current cache object.
    var cache = Connection.GetDatabase();
    var id = entity.Id;
    var key = $"MyEntity:{id}"; // The key for the cached object.
    await cache.KeyDeleteAsync(key).ConfigureAwait(false); // Delete this key from the cache.
}

Note

L’ordre dans lequel sont effectuées les étapes est important. Mettez à jour la banque de données avant de supprimer l’élément du cache. Si vous supprimez d’abord l’élément mis en cache, il existe une petite fenêtre de temps quand un client peut extraire l’élément avant la mise à jour du magasin de données. Dans ce cas, la récupération entraîne un échec de cache, car l’élément n’est pas dans le cache. Un défaut de cache fait que l'application doive récupérer l'élément obsolète à partir du magasin de données et le réintégrer dans le cache. Cette séquence entraîne des données obsolètes dans le cache.

Étapes suivantes

• Aperçu de la cohérence des données : cet aperçu décrit les problèmes de cohérence dans les données distribuées. Il résume également la façon dont une application peut implémenter une cohérence éventuelle pour maintenir la disponibilité des données. Les applications cloud stockent généralement des données dans plusieurs magasins de données et emplacements. Vous devez gérer et maintenir efficacement la cohérence des données dans cet environnement, en particulier en raison de problèmes de concurrence et de disponibilité qui peuvent survenir.

• Utilisez Azure Managed Redis comme cache sémantique : ce tutoriel vous montre comment implémenter la mise en cache sémantique à l’aide d’Azure Managed Redis.

Ressources associées

• Modèle d’application web fiable : ce modèle applique le modèle Cache-Aside aux applications web dans le cloud.

• Conseils de mise en cache : ces conseils fournissent plus d’informations sur la façon de mettre en cache des données dans une solution cloud et des problèmes à prendre en compte lorsque vous implémentez un cache.