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


Общие сведения о кэшировании в 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 браузеры обычно задают заголовки запросов, которые предотвращают кэширование. Кэширование выходных данных, доступное в .NET 7 или более поздней версии, обеспечивает преимущества приложений пользовательского интерфейса. При кэшировании выходных данных конфигурация решает, что следует кэшировать независимо от заголовков 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 браузеры обычно задают заголовки запросов, которые предотвращают кэширование. Кэширование выходных данных, доступное в .NET 7 или более поздней версии, обеспечивает преимущества приложений пользовательского интерфейса. При кэшировании выходных данных конфигурация решает, что следует кэшировать независимо от заголовков 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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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