Visão geral do cache no ASP.NET Core

Por Rick Anderson e Tom Dykstra

Cache na memória

O cache na memória usa a memória do servidor para armazenar dados em cache. Esse tipo de cache é adequado para um único servidor ou vários servidores usando afinidade de sessão. A afinidade de sessão também é conhecida como sessões persistentes. Afinidade de sessão significa que as solicitações de um cliente são sempre roteadas para o mesmo servidor para processamento.

Para obter mais informações, consulte Cache na memória no ASP.NET Core e Solucionar problemas de afinidade de sessão do Gateway de Aplicativo do Azure.

Cache distribuído

Use um cache distribuído para armazenar dados quando o aplicativo estiver hospedado em uma nuvem ou farm de servidores. O cache é compartilhado entre os servidores que processam solicitações. Um cliente pode enviar uma solicitação que é tratada por qualquer servidor do grupo se os dados armazenados em cache para o cliente estiverem disponíveis. ASP.NET Core funciona com caches distribuídos SQL Server, Redis, Postgres e NCache .

Para obter mais informações, consulte Cache distribuído no ASP.NET Core.

HybridCache

A API HybridCache preenche algumas lacunas nas APIs IDistributedCache e IMemoryCache. HybridCache é uma classe abstrata com uma implementação padrão que lida com a maioria dos aspetos de salvar em cache e recuperar do cache.

Caraterísticas

HybridCache tem os seguintes recursos que as outras APIs não têm:

• Uma API unificada para cache em processo e fora do processo.

  HybridCache foi projetado para ser um substituto imediato para o uso de IDistributedCache e IMemoryCache existentes e fornece uma API simples para adicionar novo código de cache. Se o aplicativo tiver uma implementação IDistributedCache, o serviço HybridCache o usará para cache secundário. Essa estratégia de cache de dois níveis permite que HybridCache forneça a velocidade de um cache na memória e a durabilidade de um cache distribuído ou persistente.

• Proteção contra debandada.

  Invasão de cache acontece quando uma entrada de cache usada com frequência é revogada e demasiadas solicitações tentam repopular a mesma entrada de cache ao mesmo tempo. HybridCache combina operações simultâneas, garantindo que todas as solicitações de uma determinada resposta aguarde a primeira solicitação para preencher o cache.

• Serialização configurável.

  A serialização é configurada como parte do registro do serviço, com suporte para serializadores específicos de tipo e generalizados por meio dos métodos WithSerializer e WithSerializerFactory, encadeados a partir da chamada AddHybridCache. Por padrão, o serviço lida com string e byte[] internamente e usa System.Text.Json para todo o resto. Ele pode ser configurado para outros tipos de serializadores, como protobuf ou XML.

Para ver a relativa simplicidade da API HybridCache, compare o código que a usa com o código que usa IDistributedCache. Aqui está um exemplo de como é usar 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)
    { /* ... */ }
}

Isso dá muito trabalho para acertar cada vez, incluindo aspectos como a serialização. E no cenário de "falha de cache", você pode acabar com vários threads simultâneos, todos obtendo uma falha de cache, cada um buscando os dados subjacentes, cada um serializando-os e enviando-os para o cache.

Aqui está o código equivalente usando 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
        );
    }
}

O código é mais simples e a biblioteca fornece proteção contra debandada e outros recursos que IDistributedCache não oferece.

Compatibilidade

A biblioteca HybridCache suporta tempos de execução mais antigos do .NET, até .NET Framework 4.7.2 e .NET Standard 2.0.

Recursos adicionais

Para obter mais informações, consulte os seguintes recursos:

• biblioteca HybridCache no ASP.NET Core
• Proposta de API de cache híbrido (dotnet/aspnetcore #54647)
• HybridCache código fonte

Cache de resposta

O middleware de cache para resposta:

• Permite armazenar em cache respostas do servidor com base em cabeçalhos de cache HTTP. Implementa a semântica de cache HTTP padrão. Caches baseados em cabeçalhos de cache HTTP, como fazem os proxies.
• Normalmente, não é benéfico para aplicativos de interface do usuário, como Razor Pages, porque os navegadores geralmente definem cabeçalhos de solicitação que impedem o armazenamento em cache. O cache de saída, que está disponível no .NET 7 ou posterior, beneficia os aplicativos de interface do usuário. Com o cache de saída, a configuração decide o que deve ser armazenado em cache independentemente dos cabeçalhos HTTP.
• Pode ser benéfico para pedidos públicos de API GET ou HEAD de clientes onde as condições para o cache de e são cumpridas.

Para testar o cache de respostas, use Fiddlerou outra ferramenta que possa definir explicitamente cabeçalhos de solicitação. A configuração de cabeçalhos explicitamente é preferível para testar o cache. Para obter mais informações, consulte Solução de problemas.

Para obter mais informações, consulte cache de resposta no ASP.NET Core.

Cache de saída

O middleware de cache de saída permite o cache de respostas HTTP. O cache de saída difere do cache de resposta das seguintes maneiras:

• O comportamento de cache é configurável no servidor.

  O comportamento de cache de resposta é definido por cabeçalhos HTTP. Por exemplo, quando visita um Website com o Chrome ou o Edge, o navegador envia automaticamente um cabeçalho Cache-control: max-age=0. Esse cabeçalho efetivamente desativa o cache de resposta, uma vez que o servidor segue as instruções fornecidas pelo cliente. Uma nova resposta é retornada para cada solicitação, mesmo que o servidor tenha uma nova resposta em cache. Com o cache de saída, o cliente não substitui o comportamento de cache que você configura no servidor.

• A mídia de armazenamento em cache é extensível.

  A memória é usada por padrão. O cache de resposta é limitado à memória.

• Você pode invalidar programaticamente as entradas de cache selecionadas.

  A dependência do cache de resposta em cabeçalhos HTTP deixa você com poucas opções para invalidar entradas de cache.

• O bloqueio de recursos reduz o risco de debandada de cache e rebanho trovejante.

  Invasão de cache acontece quando uma entrada de cache usada com frequência é revogada e demasiadas solicitações tentam repopular a mesma entrada de cache ao mesmo tempo. do rebanho Thundering é semelhante: uma explosão de solicitações para a mesma resposta que ainda não está em uma entrada de cache. O bloqueio de recursos garante que todas as solicitações para uma determinada resposta aguardem até que a primeira solicitação preencha o cache. O cache de resposta não tem um recurso de bloqueio de recursos.

• A revalidação de cache minimiza o uso de largura de banda.

  A revalidação de cache significa que o servidor pode retornar um código de status HTTP 304 Not Modified em vez de uma resposta em cache. Esse código de status informa ao cliente que a resposta à solicitação não foi alterada em relação ao que foi recebido anteriormente. O cache de resposta não faz a revalidação do cache.

Para obter mais informações, consulte middleware de cache de saída no ASP.NET Core.

Auxiliar de etiqueta de cache

Armazene em cache o conteúdo de uma vista MVC ou de uma página Razor com o assistente de cache. O Auxiliar de Tag de Cache usa cache na memória para armazenar dados.

Para obter mais informações, consulte Cache Tag Helper no ASP.NET Core MVC.

Auxiliar de tags de cache distribuído

Armazene o conteúdo de uma vista MVC ou de uma Página Razor em cache em cenários de nuvem distribuída ou em "web farms" com o Auxiliar de Tag de Cache Distribuído. O Auxiliar de Marca de Cache Distribuído usa o SQL Server, Redis ou NCache para armazenar dados.

Para obter mais informações, consulte Distributed Cache Tag Helper no ASP.NET Core.