Visão geral de 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 armazenamento em cache é adequado para um único servidor ou vários servidores que usam afinidade de sessão. A afinidade de sessão também é conhecida como sessões permanentes. A 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, confira 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 os dados em memória quando o aplicativo estiver hospedado em uma nuvem ou em um farm de servidores. O cache é compartilhado entre os servidores que processam as solicitações. Um cliente pode enviar uma solicitação tratada por qualquer servidor do grupo se os dados armazenados em cache para o cliente estiverem disponíveis. O ASP.NET Core funciona com caches distribuídos de SQL Server, Redis e NCache.

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

HybridCache

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

Recursos

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

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

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

• Proteção contra dispersão.

  O Estouro de cache ocorre quando uma entrada de cache usada com frequência é revogada e muitas solicitações tentam repovoar a mesma entrada de cache ao mesmo tempo. O HybridCache combina operações simultâneas, garantindo que todas as solicitações de uma determinada resposta aguardem a primeira solicitação preencher o cache.

• Serialização configurável.

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

Para ver a simplicidade relativa da API HybridCache, compare o código que a usa com o código que usa o 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)
    { /* ... */ }
}

É muito difícil acertar toda vez, incluindo aspectos como serialização. E no cenário de “perda no cache”, você pode acabar com vários threads simultâneos, todos recebendo uma perda no cache, buscando os dados subjacentes, serializando-os e enviando esses dados para o cache.

Este é 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 dispersão e outros recursos que o IDistributedCache não fornece.

Compatibilidade

A biblioteca HybridCache dá suporte a runtimes mais antigos do .NET, até o .NET Framework 4.7.2 e o .NET Standard 2.0.

Recursos adicionais

Para saber mais, consulte os recursos a seguir:

• Biblioteca do HybridCache no ASP.NET Core
• Problema do GitHub dotnet/aspnetcore nº 54647
• Código-fonte do HybridCache

Cache de resposta

O middleware de cache de resposta:

• Habilita o cache de respostas do servidor com base em cabeçalhos de cache HTTP. Implementa a semântica de cache HTTP padrão. Os caches baseados em cabeçalhos de cache HTTP, assim como fazem os proxies.
• Normalmente, não é benéfico para aplicativos de interface do usuário, como o Razor Pages, porque os navegadores geralmente definem cabeçalhos de solicitação que impedem o cache. O cache de saída, que está disponível no ASP.NET Core 7.0 e 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 solicitações públicas de API GET ou HEAD de clientes, desde que as Condições em cache para o armazenamento sejam atendidas.

Para testar o cache de resposta, use Fiddler ou outra ferramenta que possa definir explicitamente os cabeçalhos de solicitação. A configuração explícita de cabeçalhos é preferida para testar o armazenamento em cache. Para saber mais, consulte a Solução de problemas.

Para obter mais informações, confira 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 pode ser configurado no servidor.

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

• O meio de armazenamento de cache é extensível.

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

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

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

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

  O Estouro de cache ocorre quando uma entrada de cache usada com frequência é revogada e muitas solicitações tentam repovoar a mesma entrada de cache ao mesmo tempo. O Rebanho trovejante é 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 de uma determinada resposta aguardem a primeira solicitação para preencher o cache. O cache de resposta não tem um recurso de bloqueio de recursos.

• A revalidação de cache minimiza o uso da 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 um corpo de resposta em cache. Esse código de status informa ao cliente que a resposta à solicitação permanece inalterada em relação ao que foi recebido anteriormente. O cache de resposta não faz a revalidação de cache.

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

Auxiliar de Marcação de cache

Armazene em cache o conteúdo de uma exibição MVC ou Página Razor com o Auxiliar de Marca de Cache. O Auxiliar de Marca de Cache usa o cache na memória para armazenar dados.

Para obter mais informações, confira Auxiliar de Marca de Cache no ASP.NET Core MVC.

Auxiliar de Marca de Cache Distribuído

Armazene em cache o conteúdo de uma exibição MVC ou Página Razor em cenários de Web farm ou nuvem distribuída com o Auxiliar de Marca de Cache Distribuído. O Auxiliar de Marca de Cache Distribuído usa SQL Server, Redis ou NCache para armazenar dados.

Para obter mais informações, confira Auxiliar de Marca de Cache Distribuído no ASP.NET Core.