Vue d’ensemble de la mise en cache dans ASP.NET Core

Par Rick Anderson et Ryan Nowak

Mise en cache en mémoire

La mise en cache en mémoire utilise la mémoire du serveur pour stocker les données mises en cache. Ce type de mise en cache convient pour un seul serveur ou plusieurs serveurs utilisant l’affinité de session. L’affinité de session est également connue sous le terme de sessions permanentes. L’affinité de session signifie que les demandes d’un client sont toujours routées vers le même serveur pour traitement.

Pour plus d’informations, consultez Mettre en cache en mémoire dans ASP.NET Core et Résoudre les problèmes d’affinité de session Azure Application Gateway.

Cache distribué

Utilisez un cache distribué pour stocker des données lorsque l’application est hébergée dans un cloud ou une batterie de serveurs. Le cache est partagé entre les serveurs qui traitent les demandes. Un client peut envoyer une requête gérée par n’importe quel serveur du groupe si les données mises en cache pour le client sont disponibles. ASP.NET Core fonctionne avec les caches distribués SQL Server, Redis et NCache.

Pour plus d’informations, consultez Mise en cache distribuée dans ASP.NET Core.

HybridCache

L’API HybridCache permet de combler certaines lacunes dans les API IDistributedCache et IMemoryCache. HybridCache est une classe abstraite avec une implémentation par défaut qui gère la plupart des aspects de l’enregistrement dans le cache et de la récupération à partir du cache.

Fonctionnalités

HybridCache offre les fonctionnalités suivantes que les autres API n’ont pas :

• Une API unifiée pour la mise en cache in-process et out-of-process.

  HybridCache est conçue comme un remplacement de dépôt pour l’utilisation IDistributedCache et IMemoryCache existante, et elle fournit une API simple pour l’ajout de nouveau code de mise en cache. Si l’application a une implémentation IDistributedCache, le service HybridCache l’utilise pour la mise en cache secondaire. Cette stratégie de mise en cache à deux niveaux permet à HybridCache de fournir la vitesse d’un cache en mémoire et la durabilité d’un cache distribué ou persistant.

• Protection contre le tamponnement.

  L’horodatage du cache se produit lorsqu’une entrée de cache fréquemment utilisée est révoquée et qu’un trop grand nombre de demandes tentent de remplir à nouveau la même entrée de cache en même temps. HybridCache combine des opérations simultanées, garantissant ainsi que toutes les requêtes pour une réponse donnée attendent que la première requête remplisse le cache.

• Sérialisation configurable.

  La sérialisation est configurée dans le cadre de l’inscription du service, avec prise en charge des sérialiseurs propres au type et généralisés via les méthodes WithSerializer et WithSerializerFactory, chaînés à partir de l’appel AddHybridCache. Par défaut, le service gère string et byte[] en interne, et utilise System.Text.Json pour tout le reste. Il peut être configuré pour d’autres types de sérialiseurs, tels que protobuf ou XML.

Pour voir la simplicité relative de l’API HybridCache, comparez le code qui l’utilise au code qui utilise IDistributedCache. Voici un exemple de ce à quoi ressemble l’utilisation de IDistributedCache :

public class SomeService(IDistributedCache cache)
{
    public async Task<SomeInformation> GetSomeInformationAsync
        (string name, int id, CancellationToken token = default)
    {
        var key = $"someinfo:{name}:{id}"; // Unique key for this combination.
        var bytes = await cache.GetAsync(key, token); // Try to get from cache.
        SomeInformation info;
        if (bytes is null)
        {
            // Cache miss; get the data from the real source.
            info = await SomeExpensiveOperationAsync(name, id, token);

            // Serialize and cache it.
            bytes = SomeSerializer.Serialize(info);
            await cache.SetAsync(key, bytes, token);
        }
        else
        {
            // Cache hit; deserialize it.
            info = SomeSerializer.Deserialize<SomeInformation>(bytes);
        }
        return info;
    }

    // This is the work we're trying to cache.
    private async Task<SomeInformation> SomeExpensiveOperationAsync(string name, int id,
        CancellationToken token = default)
    { /* ... */ }
}

Cela représente beaucoup de travail à faire correctement à chaque fois, y compris des choses comme la sérialisation. Et dans le scénario d’« échec d’accès au cache », vous risquez de vous retrouver avec plusieurs threads simultanés, tous obtenant un échec d’accès au cache, tous récupérant les données sous-jacentes, tous les sérialisant, et tous envoyant ces données au cache.

Voici du code équivalent utilisant HybridCache :

public class SomeService(HybridCache cache)
{
    public async Task<SomeInformation> GetSomeInformationAsync
        (string name, int id, CancellationToken token = default)
    {
        return await cache.GetOrCreateAsync(
            $"someinfo:{name}:{id}", // Unique key for this entry.
            async cancel => await SomeExpensiveOperationAsync(name, id, cancel),
            token: token
        );
    }
}

Le code est plus simple, et la bibliothèque fournit une protection contre le tamponnement et d’autres fonctionnalités absentes de IDistributedCache.

Compatibilité

La bibliothèque prend en charge les runtimes .NET plus anciens, jusqu’à .NET Framework 4.7.2 et .NET Standard 2.0.

Ressources supplémentaires

Pour plus d’informations, consultez les ressources suivantes :

• Bibliothèque HybridCache dans ASP.NET Core
• GitHub issue dotnet/aspnetcore #54647
• Code source HybridCache

Tag Helper de cache

Mettez en cache le contenu d’une vue ou d’une Razor page MVC avec le Tag Helper de cache. Le Tag Helper cache utilise la mise en cache en mémoire pour stocker les données.

Pour plus d’informations, consultez assistance des balises de cache dans ASP.NET Core MVC.

Tag Helper Cache distribué

Mettez en cache le contenu à partir d’une vue MVC ou d’une Razor page dans des scénarios cloud distribué ou de batterie de serveurs web avec le tag Helper du cache distribué. Le Tag Helper du cache distribué utilise SQL Server, Redis ou NCache pour stocker des données.

Pour plus d’informations, consultez assistance distribuée des balises de cache dans ASP.NET Core.

Mise en cache des réponses

L’intergiciel de mise en cache des réponses :

• Active la mise en cache des réponses du serveur en fonction des en-têtes de cache HTTP. Implémente la sémantique de mise en cache HTTP standard. Caches basés sur des en-têtes de cache HTTP comme les proxys.
• N’est généralement pas bénéfique pour les applications d’interface utilisateur telles que Razor Pages, car les navigateurs définissent habituellement des en-têtes de requête qui empêchent la mise en cache. La mise en cache de sortie, disponible dans ASP.NET Core 7.0 et versions ultérieures, bénéficie aux applications d’interface utilisateur. Avec la mise en cache de sortie, la configuration détermine ce qui doit être mis en cache indépendamment des en-têtes HTTP.
• Peut être utile pour les demandes d’API GET ou HEAD publiques provenant de clients pour lesquels les conditions de mise en cache sont remplies.

Pour tester la mise en cache des réponses, utilisez Fiddler ou un autre outil qui peut définir explicitement des en-têtes de requête. La définition explicite d’en-têtes est recommandée pour tester la mise en cache. Pour plus d’informations, consultez la page Dépannage.

Mise en cache de la sortie

L’intergiciel de mise en cache de sortie permet la mise en cache des réponses HTTP. La mise en cache de sortie diffère de la mise en cache des réponses des manières suivantes :

• Le comportement de mise en cache est configurable sur le serveur.

  Le comportement de mise en cache des réponses est défini par les en-têtes HTTP. Par exemple, lorsque vous visitez un site web avec Chrome ou Edge, le navigateur envoie automatiquement un Cache-control: max-age=0 en-tête. Cet en-tête désactive efficacement la mise en cache des réponses, car le serveur suit les instructions fournies par le client. Une nouvelle réponse est retournée pour chaque requête, même si le serveur a une nouvelle réponse mise en cache. Avec la mise en cache de sortie, le client ne remplace pas le comportement de mise en cache que vous configurez sur le serveur.

• Le support de stockage du cache est extensible.

  La mémoire est utilisée par défaut. La mise en cache des réponses est limitée à la mémoire.

• Vous pouvez invalider par programmation les entrées de cache sélectionnées.

  La dépendance de la mise en cache des réponses vis-à-vis des en-têtes HTTP vous laisse peu d’options pour invalider les entrées de cache.

• Le verrouillage des ressources atténue le risque de tamponnement du cache et de troupeau tonitruant.

  L’horodatage du cache se produit lorsqu’une entrée de cache fréquemment utilisée est révoquée et qu’un trop grand nombre de demandes tentent de remplir à nouveau la même entrée de cache en même temps. Le troupeau tonitruant est similaire : une rafale de demandes pour la même réponse qui n’est pas déjà dans une entrée de cache. Le verrouillage des ressources garantit que toutes les requêtes pour une réponse donnée attendent que la première demande remplisse le cache. La mise en cache des réponses n’a pas de fonctionnalité de verrouillage des ressources.

• La revalidation du cache réduit l’utilisation de la bande passante.

  La revalidation du cache signifie que le serveur peut retourner un code d’état HTTP 304 Not Modified au lieu d’un corps de réponse mis en cache. Ce code statut informe le client que la réponse à la requête est inchangée par rapport à ce qui a été reçu précédemment. La mise en cache des réponses ne fait pas de revalidation du cache.