Общие сведения о кэшировании в ASP.NET Core

Авторы: Рик Андерсон (Rick Anderson) и Том Дайкстра (Tom Dykstra)

Кэширование в памяти

Кэширование в памяти использует память сервера для хранения кэшированных данных. Этот тип кэширования подходит для одного сервера или нескольких серверов, использующих сходство сеансов. Сходство сеансов также называется липкими сеансами. Сходство сеансов означает, что запросы от клиента всегда направляются на тот же сервер для обработки.

Дополнительные сведения см. в разделе "Кэш в памяти" в ASP.NET Core и устранение неполадок с сходством сеансов Шлюз приложений Azure.

Распределенный кэш

Используйте распределенный кэш для хранения данных, когда приложение размещается в облачной или серверной ферме. Кэш используется на серверах, обрабатывающих запросы. Клиент может отправить запрос, который обрабатывается любым сервером в группе, если кэшированные данные для клиента доступны. ASP.NET Core работает с распределенными кэшами SQL Server, Redis и NCache .

Дополнительные сведения см. в статье Распределенное кэширование в ASP.NET Core.

HybridCache

HybridCache API мостит некоторые пробелы в IDistributedCache API и IMemoryCache API. HybridCache — абстрактный класс с реализацией по умолчанию, которая обрабатывает большинство аспектов сохранения в кэше и извлечения из кэша.

Функции

HybridCache имеет следующие функции, у которых другие API-интерфейсы не имеют:

• Унифицированный API для кэширования как внутри процесса, так и для внепроцессного кэширования.

  HybridCache предназначен для замены существующего IDistributedCache и IMemoryCache использования и предоставляет простой API для добавления нового кода кэширования. Если у приложения есть IDistributedCache реализация, HybridCache служба использует ее для дополнительного кэширования. Эта двухуровневая стратегия кэширования позволяет HybridCache обеспечить скорость кэша в памяти и устойчивость распределенного или постоянного кэша.

• Защита с меткой.

  Метка кэша происходит, когда часто используемая запись кэша отозвана, и слишком много запросов пытаются повторно заполнить одну запись кэша одновременно. HybridCache объединяет параллельные операции, гарантируя, что все запросы для заданного ответа ожидают первого запроса для заполнения кэша.

• Настраиваемая сериализация.

  Сериализация настраивается как часть регистрации службы, с поддержкой типовых и обобщенных сериализаторов через WithSerializer методы и WithSerializerFactory методы, связанные с вызовом AddHybridCache . По умолчанию служба обрабатывает string и byte[] внутренне и использует System.Text.Json все остальное. Его можно настроить для других типов сериализаторов, таких как protobuf или XML.

Чтобы увидеть относительную простоту HybridCache API, сравните код, который использует его для кода, который использует IDistributedCache. Ниже приведен пример 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)
    { /* ... */ }
}

Это много работы, чтобы получить право каждый раз, включая вещи, такие как сериализация. И в сценарии "пропустить кэш" можно в конечном итоге с несколькими параллельными потоками, все получение пропущенных кэша, получение всех базовых данных, сериализация всех данных и все отправки этих данных в кэш.

Ниже приведен эквивалентный код с помощью 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
        );
    }
}

Код проще, и библиотека обеспечивает защиту от меток и другие функции, которые IDistributedCache не поддерживаются.

Совместимость

Библиотека HybridCache поддерживает старые среды выполнения .NET до платформа .NET Framework 4.7.2 и .NET Standard 2.0.

Дополнительные ресурсы

Дополнительные сведения см. на следующих ресурсах:

• Библиотека HybridCache в ASP.NET Core
• Проблема GitHub dotnet/aspnetcore #54647
• Исходный код HybridCache

Вспомогательная функция тега кэша

Кэшируйте содержимое из представления или Razor страницы MVC с помощью вспомогательного средства тега кэша. Вспомогательный элемент тега кэша использует кэширование в памяти для хранения данных.

Дополнительные сведения см . в справке по тегу кэша в ASP.NET Core MVC.

Вспомогательная функция тега распределенного кэша

Кэшируйте содержимое из представления MVC или Razor страницы в сценариях распределенной облачной или веб-фермы с помощью вспомогательного средства тега распределенного кэша. Помощник по тегу распределенного кэша использует SQL Server, Redis или NCache для хранения данных.

Дополнительные сведения см . в справке по тегу тега распределенного кэша в ASP.NET Core.

кэширование ответов;

По промежуточному слоям кэширования ответа:

• Включает кэширование ответов сервера на основе заголовков кэша HTTP. Реализует стандартную семантику кэширования HTTP. Кэши на основе заголовков кэша HTTP, таких как прокси-серверы.
• Обычно не подходит для приложений пользовательского интерфейса, таких как Pages, так как Razor браузеры обычно задают заголовки запросов, которые предотвращают кэширование. Кэширование выходных данных, доступное в ASP.NET Core 7.0 и более поздних версий, обеспечивает преимущества приложений пользовательского интерфейса. При кэшировании выходных данных конфигурация решает, что следует кэшировать независимо от заголовков HTTP.
• Может оказаться полезным для общедоступных запросов GET или HEAD API от клиентов, где выполняются условия кэширования .

Чтобы проверить кэширование ответов, используйте Fiddler или другое средство, которое может явно задать заголовки запросов. Для тестирования кэширования предпочтительнее явно задать заголовки. Дополнительные сведения см. в разделе Устранение неполадок.

Кэширование вывода

Выходное ПО промежуточного слоя кэширования позволяет кэширование http-ответов. Кэширование выходных данных отличается от кэширования ответов следующими способами:

• Поведение кэширования настраивается на сервере.

  Поведение кэширования ответа определяется заголовками HTTP. Например, при посещении веб-сайта с chrome или Edge браузер автоматически отправляет Cache-control: max-age=0 заголовок. Этот заголовок фактически отключает кэширование ответов, так как сервер следует указаниям, предоставленным клиентом. Новый ответ возвращается для каждого запроса, даже если сервер имеет свежий кэшированный ответ. При кэшировании выходных данных клиент не переопределяет поведение кэширования, настроенного на сервере.

• Среда хранилища кэша расширяема.

  Память используется по умолчанию. Кэширование ответов ограничено памятью.

• Вы можете программным способом отключить выбранные записи кэша.

  Зависимость кэширования ответов от заголовков HTTP оставляет вас с несколькими вариантами для недопустимых записей кэша.

• Блокировка ресурсов снижает риск метки кэша и гром стада.

  Метка кэша происходит, когда часто используемая запись кэша отозвана, и слишком много запросов пытаются повторно заполнить одну запись кэша одновременно. Грома стада аналогична: всплеск запросов на тот же ответ, который еще не находится в записи кэша. Блокировка ресурсов гарантирует, что все запросы для заданного ответа ожидают первого запроса, чтобы заполнить кэш. Кэширование ответов не имеет функции блокировки ресурсов.

• Повторная проверка кэша сводит к минимуму использование пропускной способности.

  Повторная проверка кэша означает, что сервер может возвращать 304 Not Modified код состояния HTTP вместо кэшированного текста ответа. Этот код состояния сообщает клиенту, что ответ на запрос не изменяется от того, что было получено ранее. Кэширование ответов не выполняет повторную настройку кэша.