Поделиться через


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

Примечание.

Это не последняя версия этой статьи. В текущем выпуске смотрите эту статью, касающуюся версии .NET 9.

Предупреждение

Эта версия ASP.NET Core больше не поддерживается. Дополнительные сведения см. в политике поддержки .NET и .NET Core. В текущем выпуске см . версию .NET 9 этой статьи.

Внимание

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

В этом выпуске см. статью о версии .NET 9.

Авторы: Рик Андерсон (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.

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

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

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

Промежуточное ПО для кэширования ответов.

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

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

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

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

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

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

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

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

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

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

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

  • Блокировка ресурсов снижает риск наплыва обращений к кэшу и эффекта гремящего стада.

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

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

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

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

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

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

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

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

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

Для получения дополнительной информации см. Помощник тегов распределенного кэша в ASP.NET Core.

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

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

Дополнительные сведения см. в разделе Кэш в памяти в 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.

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

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

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

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

Дополнительные сведения см . в справке по тегу кэша в 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 вместо кэшированного текста ответа. Этот код состояния сообщает клиенту, что ответ на запрос не изменяется от того, что было получено ранее. Кэширование ответов не выполняет повторную проверку кэша.

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

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

Дополнительные сведения см. в разделах «Кэширование в памяти в 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.

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

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

Помощник тегов кэша

Кэшируйте содержимое из представления или 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 или другое средство, которое может явно задать заголовки запросов. Для тестирования кэширования предпочтительнее явно задать заголовки. Дополнительные сведения см. в разделе Устранение неполадок.

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

Кэширование выходных данных доступно в .NET 7 и более поздних версиях.