Visão geral de cache no ASP.NET Core

Observação

Esta não é a versão mais recente deste artigo. Para a versão atual, consulte a versão do .NET 10 deste artigo.

Aviso

Esta versão do ASP.NET Core não tem mais suporte. Para obter mais informações, consulte a Política de Suporte do .NET e do .NET Core. Para a versão atual, consulte a versão do .NET 10 deste artigo.

Por Rick Anderson e Tom Dykstra

Este artigo fornece uma visão geral do cache em ASP.NET Core com uma introdução ao cache na memória, distribuído, híbrido, resposta e saída.

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 que usam afinidade de sessão. A afinidade de sessão também é conhecida como sessões persistentes. 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 que é manipulada por qualquer servidor no grupo quando os dados armazenados em cache para o cliente estão disponíveis. ASP.NET Core funciona com caches distribuídos do SQL Server, Redis, Postgres e NCache .

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

HybridCache

A HybridCache API preenche lacunas entre as 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 do HybridCache

HybridCache fornece os seguintes recursos que não estão disponíveis com outras APIs:

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

    HybridCache foi projetado para ser um substituto direto para o uso existente de IDistributedCache e IMemoryCache, e fornece uma API simples para adicionar 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 Efeito manada de cache ocorre quando uma entrada de cache usada com frequência é invalidada e muitas solicitações tentam repopular a mesma entrada de cache ao mesmo tempo. HybridCache combina operações simultâneas, o que garante que todas as solicitações de uma determinada resposta aguardem a primeira solicitação para preencher o cache.

  • Serialização configurável.

    A serialização é configurada ao registrar o serviço, com suporte para serializadores específicos e genéricos por meio dos métodos WithSerializer e WithSerializerFactory, encadeados da chamada AddHybridCache. Por padrão, o serviço manipula os tipos string e byte[] internamente e usa o namespace System.Text.Json para todo o resto. HybridCache 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)
    { /* ... */ }
}

O código demonstra uma quantidade significativa de trabalho para acertar a cada vez, incluindo itens como serialização. Também no cenário de "falha de cache", é possível que você termine com vários threads simultâneos. Esses threads podem todos receber uma falha de cache, buscar os dados subjacentes, serializá-los e enviar todos os dados para o cache.

Aqui está o código equivalente que usa a HybridCache API:

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 não disponíveis com a IDistributedCache interface.

Compatibilidade

A biblioteca HybridCache dá suporte a runtimes de .NET mais antigos, incluindo .NET Framework 4.7.2 e .NET Standard 2.0.

Mais informações

Para saber mais, consulte os recursos a seguir:

Cache de resposta

O middleware de cache de resposta permite armazenar em cache respostas do servidor com base em cabeçalhos de Cache-Control HTTP.

  • O comportamento de cache implementa a semântica de cache HTTP padrão.

  • O cache é baseado em cabeçalhos de cache HTTP semelhantes ao método usado por proxies.

  • Essa forma de cache é útil para solicitações públicas da API GET ou HEAD de clientes em que as condições de cache são atendidas.

  • Para aplicativos de interface do usuário, como Razor Páginas, o cache de resposta normalmente não é benéfico. Os navegadores geralmente definem cabeçalhos de solicitação que impedem o cache.

    O Cache de Saída (disponível no .NET 7 e posterior) é uma abordagem superior para aplicativos UI. Nesse cenário, a configuração determina o que armazenar em cache independentemente de cabeçalhos HTTP.

Para testar o cache de resposta, use o Fiddler ou outra ferramenta que possa definir explicitamente cabeçalhos de solicitação. A configuração explícita de cabeçalhos é preferida para testar o armazenamento em cache. Para obter mais informações, consulte O middleware de cache de resposta 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 é configurável no servidor.

    O comportamento de cache de resposta é definido com cabeçalhos HTTP. Por exemplo, quando você navega em um site com Chrome ou Microsoft Edge, o navegador envia automaticamente um cabeçalho Cache-control: max-age=0. Esse cabeçalho efetivamente desabilita o cache de resposta porque 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 que você configura 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.

    O cache de resposta depende de cabeçalhos HTTP, o que deixa você com poucas opções para invalidar entradas de cache.

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

    O Efeito manada de cache ocorre quando uma entrada de cache usada com frequência é invalidada e muitas solicitações tentam repopular 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 não modificado 304 em vez de um corpo de resposta armazenado 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 Tag 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 mais informações, consulte Tag Helper de Cache Distribuído no ASP.NET Core.

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 persistentes. 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. ASP.NET Core funciona com caches distribuídos do SQL Server, Redis, Postgres e NCache .

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

HybridCache

A HybridCache API preenche lacunas entre as 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 do HybridCache

HybridCache fornece os seguintes recursos que não estão disponíveis com outras APIs:

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

    HybridCache foi projetado para ser um substituto direto para o uso existente de IDistributedCache e IMemoryCache, e fornece uma API simples para adicionar 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 Efeito manada de cache ocorre quando uma entrada de cache usada com frequência é invalidada e muitas solicitações tentam repopular a mesma entrada de cache ao mesmo tempo. HybridCache combina operações simultâneas, o que garante que todas as solicitações de uma determinada resposta aguardem a primeira solicitação para preencher o cache.

  • Serialização configurável.

    A serialização é configurada ao registrar o serviço, com suporte para serializadores específicos e genéricos por meio dos métodos WithSerializer e WithSerializerFactory, encadeados da chamada AddHybridCache. Por padrão, o serviço manipula os tipos string e byte[] internamente e usa o namespace System.Text.Json para todo o resto. HybridCache 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)
    { /* ... */ }
}

O código demonstra uma quantidade significativa de trabalho para acertar a cada vez, incluindo itens como serialização. Também no cenário de "falha de cache", é possível que você termine com vários threads simultâneos. Esses threads podem todos receber uma falha de cache, buscar os dados subjacentes, serializá-los e enviar todos os dados para o cache.

Aqui está o código equivalente que usa a HybridCache API:

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 não disponíveis com a IDistributedCache interface.

Compatibilidade

A biblioteca HybridCache dá suporte a runtimes de .NET mais antigos, incluindo .NET Framework 4.7.2 e .NET Standard 2.0.

Mais informações

Para saber mais, consulte os recursos a seguir:

Cache Tag Helper

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 Tag 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.

Cache de resposta

O middleware de cache de resposta permite o cache de respostas do servidor com base nos cabeçalhos HTTP Cache-Control.

  • O comportamento de cache implementa a semântica de cache HTTP padrão.

  • O cache é baseado em cabeçalhos de cache HTTP semelhantes ao método usado por proxies.

  • Essa forma de cache é útil para solicitações públicas da API GET ou HEAD de clientes em que as condições de cache são atendidas.

  • Para aplicativos de interface do usuário, como Razor Páginas, o cache de resposta normalmente não é benéfico. Os navegadores geralmente definem cabeçalhos de solicitação que impedem o cache.

    Cache de saída (disponível no .NET 7 e posterior) é uma abordagem melhor para aplicativos de UI. Nesse cenário, a configuração determina o que armazenar em cache independentemente de cabeçalhos HTTP.

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

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 relação do cache de resposta com os 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 Efeito manada de cache ocorre quando uma entrada de cache usada com frequência é invalidada e muitas solicitações tentam repopular 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.

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 persistentes. 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. ASP.NET Core funciona com caches distribuídos do SQL Server, Redis, Postgres e NCache .

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

HybridCache

A HybridCache API preenche lacunas entre as 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 do HybridCache

HybridCache fornece os seguintes recursos que não estão disponíveis com outras APIs:

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

    HybridCache foi projetado para ser um substituto direto para o uso existente de IDistributedCache e IMemoryCache, e fornece uma API simples para adicionar 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 Efeito manada de cache ocorre quando uma entrada de cache usada com frequência é invalidada e muitas solicitações tentam repopular a mesma entrada de cache ao mesmo tempo. HybridCache combina operações simultâneas, o que garante que todas as solicitações de uma determinada resposta aguardem a primeira solicitação para preencher o cache.

  • Serialização configurável.

    A serialização é configurada ao registrar o serviço, com suporte para serializadores específicos e genéricos por meio dos métodos WithSerializer e WithSerializerFactory, encadeados da chamada AddHybridCache. Por padrão, o serviço manipula os tipos string e byte[] internamente e usa o namespace System.Text.Json para todo o resto. HybridCache 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)
    { /* ... */ }
}

O código demonstra uma quantidade significativa de trabalho para acertar a cada vez, incluindo itens como serialização. Também no cenário de "falha de cache", é possível que você termine com vários threads simultâneos. Esses threads podem todos receber uma falha de cache, buscar os dados subjacentes, serializá-los e enviar todos os dados para o cache.

Aqui está o código equivalente que usa a HybridCache API:

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 não disponíveis com a IDistributedCache interface.

Compatibilidade

A biblioteca HybridCache dá suporte a runtimes de .NET mais antigos, incluindo .NET Framework 4.7.2 e .NET Standard 2.0.

Mais informações

Para saber mais, consulte os recursos a seguir:

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 Tag 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 mais informações, consulte Tag Helper de Cache Distribuído no ASP.NET Core.

Cache de resposta

O middleware de cache de resposta permite armazenar em cache respostas do servidor com base em cabeçalhos de Cache-Control HTTP.

  • O comportamento de cache implementa a semântica de cache HTTP padrão.

  • O cache é baseado em cabeçalhos de cache HTTP semelhantes ao método usado por proxies.

  • Essa forma de cache é útil para solicitações públicas da API GET ou HEAD de clientes em que as condições de cache são atendidas.

  • Para aplicativos de interface do usuário, como Razor Páginas, o cache de resposta normalmente não é benéfico. Os navegadores geralmente definem cabeçalhos de solicitação que impedem o cache.

    O Cache de Saída (disponível no .NET 7 e posterior) é uma abordagem superior para aplicativos UI. Nesse cenário, a configuração determina o que armazenar em cache independentemente de cabeçalhos HTTP.

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

Cache de saída

O cache de saída está disponível no .NET 7 ou posterior.

Conteúdo relacionado

  • Last updated on