Información general sobre el almacenamiento en caché en ASP.NET Core

Por Rick Anderson y Tom Dykstra

Almacenamiento en caché en memoria

El almacenamiento en caché en memoria usa la memoria del servidor para almacenar los datos almacenados en caché. Este tipo de almacenamiento en caché es adecuado para un solo servidor o varios servidores mediante la afinidad de sesión. La afinidad de sesión también se conoce como sesiones persistentes. La afinidad de sesión significa que las solicitudes de un cliente siempre se enrutan al mismo servidor para su procesamiento.

Para más información, consulte Caché en memoria en ASP.NET Core y Solución de problemas de afinidad de sesión de Azure Application Gateway.

Caché distribuida

Use una caché distribuida para almacenar datos cuando la aplicación se hospede en una nube o granja de servidores. La memoria caché se comparte entre los servidores que procesan las solicitudes. Un cliente puede enviar una solicitud que controla cualquier servidor del grupo si los datos almacenados en caché del cliente están disponibles. ASP.NET Core funciona con cachés distribuidas de SQL Server, Redis y NCache.

Para más información, consulte Almacenamiento en caché distribuido en ASP.NET Core.

HybridCache

La API HybridCache puentea algunas lagunas en las API IDistributedCache y IMemoryCache. HybridCache es una clase abstracta que controla la mayoría de los aspectos de guardar en caché y recuperar de la memoria caché.

Características

HybridCache tiene las siguientes características que las otras API no tienen:

• Una API unificada para el almacenamiento en caché en proceso y fuera de proceso.

  HybridCache está diseñado como un reemplazo directo para el uso de IDistributedCache y IMemoryCache existentes, y proporciona una API sencilla para agregar código de almacenamiento en caché nuevo. Si la aplicación tiene una implementación IDistributedCache, el servicio HybridCachela usa para el almacenamiento en caché secundario. Esta estrategia de almacenamiento en caché de dos niveles permite a HybridCache proporcionar la velocidad de una caché en memoria y la durabilidad de una caché distribuida o persistente.

• Protección de "Stampede".

  El fallo en cascada de caché se produce cuando se revoca una entrada de caché usada con frecuencia y demasiadas solicitudes intentan volver a rellenar la misma entrada de caché al mismo tiempo. HybridCache combina operaciones simultáneas, lo que garantiza que todas las solicitudes de una respuesta determinada esperen a que la primera solicitud rellene la memoria caché.

• Serialización configurable.

  La serialización se configura como parte del registro del servicio, con compatibilidad con serializadores específicos de tipos y generalizados a través de los métodos WithSerializer y WithSerializerFactory, encadenados desde la llamada AddHybridCache. De forma predeterminada, el servicio controla internamente string y byte[], y usa System.Text.Json para todo lo demás. Se puede configurar para otros tipos de serializadores, como Protobuf o XML.

Para ver la simplicidad relativa de la API HybridCache, compare el código que lo usa con el código que usa IDistributedCache. Este es un ejemplo del aspecto que tiene el 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)
    { /* ... */ }
}

Eso supone mucho trabajo para conseguir hacerlo bien cada vez, incluyendo cosas como la serialización. Y en el escenario de "pérdida de caché", podría acabar con varios subprocesos simultáneos, obtener una falta de caché, capturar todos los datos subyacentes, serializarlos y enviar esos datos a la memoria caché.

Este es el código equivalente mediante 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
        );
    }
}

El código es más sencillo y la biblioteca dan protección de "Stampede" y otras características que IDistributedCache no proporciona.

Compatibilidad

La biblioteca admite entornos de ejecución de .NET anteriores, hasta .NET Framework 4.7.2 y .NET Standard 2.0.

Recursos adicionales

Para obtener más información, consulte los siguientes recursos:

• Biblioteca HybridCache en ASP.NET Core
• Problema de GitHub dotnet/aspnetcore #54647
• Código fuente HybridCache

Asistente de etiquetas de caché

Almacene en caché el contenido de una vista de MVC o una página de Razor con el asistente de etiquetas de caché. El asistente de etiquetas de caché usa el almacenamiento en caché en memoria para almacenar datos.

Para más información, consulte Asistente de etiquetas de caché en ASP.NET Core MVC.

Asistente de etiquetas de caché distribuida

Almacene en caché el contenido de una vista de MVC o una página de Razor en escenarios distribuidos de la nube o granja de servidores web con el asistente de etiquetas de caché distribuida. El asistente de etiquetas de caché distribuida usa SQL Server, Redis o NCache para almacenar datos.

Para obtener más información, consulte Asistente de etiquetas de caché distribuida en ASP.NET Core.

Almacenamiento en caché de respuesta

Middleware de almacenamiento en caché de respuestas:

• Habilita el almacenamiento en caché de respuestas del servidor basadas en encabezados de caché HTTP. Implementa la semántica de almacenamiento en caché HTTP estándar. Cachés basadas en encabezados de caché HTTP, como los servidores proxy.
• Normalmente no se recomienda en aplicaciones de interfaz de usuario, como Razor Pages, porque los exploradores suelen establecer encabezados de solicitud que impiden el almacenamiento en caché. El almacenamiento en caché de resultados, que está disponible en ASP.NET Core 7.0 y versiones posteriores, beneficia a las aplicaciones de interfaz de usuario. Con el almacenamiento en caché de resultados, la configuración decide qué se debe almacenar en caché independientemente de los encabezados HTTP.
• Puede ser beneficioso para las solicitudes públicas de API HEAD o GET de los clientes en los que se cumplen las condiciones para el almacenamiento en caché.

Para probar el almacenamiento en caché de respuestas, use Fiddler u otra herramienta que pueda establecer explícitamente encabezados de solicitud. Se prefiere establecer explícitamente los encabezados para probar el almacenamiento en caché. Para más información, consulte Solución de problemas.

Almacenamiento en caché de resultados

El middleware de almacenamiento en caché de resultados permite el almacenamiento en caché de respuestas HTTP. El almacenamiento en caché de salida difiere del almacenamiento en caché de resultados de las siguientes maneras:

• El comportamiento de almacenamiento en caché se puede configurar en el servidor.

  El comportamiento del almacenamiento en caché de respuesta se define mediante encabezados HTTP. Por ejemplo, cuando visita un sitio web con Chrome o Edge, el explorador envía automáticamente un encabezado de Cache-control: max-age=0. Este encabezado deshabilita eficazmente el almacenamiento en caché de respuestas, ya que el servidor sigue las instrucciones proporcionadas por el cliente. Se devuelve una nueva respuesta para cada solicitud, incluso si el servidor tiene una respuesta almacenada en caché nueva. Con el almacenamiento en caché de resultados, el cliente no invalida el comportamiento de almacenamiento en caché que configure en el servidor.

• El medio de almacenamiento en caché es extensible.

  La memoria se usa de forma predeterminada. El almacenamiento en caché de respuestas está limitado a la memoria.

• Puede invalidar mediante programación las entradas de caché seleccionadas.

  La dependencia del almacenamiento en caché de respuesta en los encabezados HTTP le deja con algunas opciones para invalidar las entradas de caché.

• El bloqueo de recursos mitiga el riesgo de fallo en cascada y colapso por activación simultánea de varios hilos de ejecución (thundering herd).

  El fallo en cascada de caché se produce cuando se revoca una entrada de caché usada con frecuencia y demasiadas solicitudes intentan volver a rellenar la misma entrada de caché al mismo tiempo. El colapso por activación simultánea de varios hilos de ejecución es similar: una ráfaga de solicitudes para la misma respuesta que aún no está en una entrada de caché. El bloqueo de recursos garantiza que todas las solicitudes de una respuesta determinada esperen a que la primera solicitud rellene la memoria caché. El almacenamiento en caché de respuestas no tiene una característica de bloqueo de recursos.

• La revalidación de caché minimiza el uso del ancho de banda.

  La revalidación de caché significa que el servidor puede devolver un código de estado HTTP 304 Not Modified en lugar de un cuerpo de respuesta almacenado en caché. Este código de estado informa al cliente de que la respuesta a la solicitud no cambia de lo que se recibió anteriormente. El almacenamiento en caché de respuesta no hace revalidación de la memoria caché.