Omówienie buforowania w programie ASP.NET Core

Autor : Rick Anderson i Tom Dykstra

Buforowanie w pamięci

Buforowanie w pamięci używa pamięci serwera do przechowywania buforowanych danych. Ten typ buforowania jest odpowiedni dla jednego serwera lub wielu serwerów przy użyciu koligacji sesji. Koligacja sesji jest również znana jako sesje sticky. Koligacja sesji oznacza, że żądania od klienta są zawsze kierowane do tego samego serwera do przetwarzania.

Aby uzyskać więcej informacji, zobacz Buforowanie w pamięci w programie ASP.NET Core i Rozwiązywanie problemów z koligacją sesji bramy aplikacja systemu Azure.

Rozproszona pamięć podręczna

Użyj rozproszonej pamięci podręcznej do przechowywania danych, gdy aplikacja jest hostowana w farmie serwerów lub w chmurze. Pamięć podręczna jest współdzielona na serwerach, które przetwarzają żądania. Klient może przesłać żądanie obsługiwane przez dowolny serwer w grupie, jeśli dane buforowane dla klienta są dostępne. ASP.NET Core współpracuje z rozproszonymi pamięciami podręcznymi sql Server, Redis i NCache .

Aby uzyskać więcej informacji, zobacz Buforowanie rozproszone w usłudze ASP.NET Core.

Hybrydowa usługaCache

Interfejs HybridCache API łączy pewne luki w interfejsach IDistributedCache API i IMemoryCache . HybridCache jest abstrakcyjną klasą z domyślną implementacją, która obsługuje większość aspektów zapisywania w pamięci podręcznej i pobierania z pamięci podręcznej.

Funkcje

HybridCache ma następujące funkcje, których nie mają inne interfejsy API:

• Ujednolicony interfejs API zarówno w przypadku buforowania procesowego, jak i poza procesem.

  HybridCache jest przeznaczony do zastąpienia upuszczania dla istniejących IDistributedCache i IMemoryCache użycia, a także udostępnia prosty interfejs API do dodawania nowego kodu buforowania. Jeśli aplikacja ma implementację IDistributedCache , HybridCache usługa używa jej do buforowania pomocniczego. Ta dwuwymiarowa strategia buforowania umożliwia HybridCache zapewnienie szybkości pamięci podręcznej w pamięci oraz trwałości rozproszonej lub trwałej pamięci podręcznej.

• Ochrona stampede.

  Sygnatura pamięci podręcznej występuje, gdy często używany wpis pamięci podręcznej jest odwoływane, a zbyt wiele żądań próbuje ponownie wypełniać ten sam wpis pamięci podręcznej w tym samym czasie. HybridCache łączy operacje współbieżne, zapewniając, że wszystkie żądania dla danej odpowiedzi oczekują na pierwsze żądanie wypełnienia pamięci podręcznej.

• Konfigurowalna serializacji.

  Serializacja jest konfigurowana w ramach rejestrowania usługi z obsługą serializatorów specyficznych dla typu i uogólnionych za pośrednictwem WithSerializer metod i WithSerializerFactory , w łańcuchu od wywołania AddHybridCache . Domyślnie usługa obsługuje string i byte[] wewnętrznie używa System.Text.Json wszystkich innych elementów. Można go skonfigurować dla innych typów serializatorów, takich jak protobuf lub XML.

Aby zobaczyć względną prostotę interfejsu HybridCache API, porównaj kod, który używa go do kodu używającego metody IDistributedCache. Oto przykład użycia 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)
    { /* ... */ }
}

To dużo pracy, aby uzyskać rację za każdym razem, w tym takie rzeczy jak serializacja. W scenariuszu "chybienia pamięci podręcznej" można znaleźć wiele współbieżnych wątków, wszystkie chybienie pamięci podręcznej, wszystkie pobieranie danych bazowych, wszystkie serializowanie ich i wysyłanie tych danych do pamięci podręcznej.

Oto równoważny kod przy użyciu polecenia 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
        );
    }
}

Kod jest prostszy, a biblioteka zapewnia ochronę stampede i inne funkcje, które IDistributedCache nie.

Zgodność

Biblioteka HybridCache obsługuje starsze środowiska uruchomieniowe platformy .NET w dół do programów .NET Framework 4.7.2 i .NET Standard 2.0.

Dodatkowe zasoby

Aby uzyskać więcej informacji, zobacz następujące zasoby:

• Biblioteka hybridCache w programie ASP.NET Core
• Problem z usługą GitHub dotnet/aspnetcore #54647
• HybridCache kod źródłowy

Buforowanie odpowiedzi

Oprogramowanie pośredniczące buforowania odpowiedzi:

• Włącza buforowanie odpowiedzi serwera na podstawie nagłówków pamięci podręcznej HTTP. Implementuje standardową semantykę buforowania HTTP. Pamięci podręczne oparte na nagłówkach pamięci podręcznej HTTP, takich jak serwery proxy.
• Zazwyczaj nie jest korzystne dla aplikacji interfejsu użytkownika, takich jak Razor Strony, ponieważ przeglądarki zwykle ustawiają nagłówki żądań, które uniemożliwiają buforowanie. Buforowanie danych wyjściowych, które jest dostępne w programie ASP.NET Core 7.0 lub nowszym, zapewnia korzyści aplikacjom interfejsu użytkownika. W przypadku buforowania danych wyjściowych konfiguracja decyduje, co powinno być buforowane niezależnie od nagłówków HTTP.
• Może być korzystne w przypadku publicznych żądań GET lub HEAD API od klientów, na których spełnione są warunki buforowania .

Aby przetestować buforowanie odpowiedzi, użyj programu Fiddler lub innego narzędzia, które może jawnie ustawić nagłówki żądań. Jawne ustawianie nagłówków jest preferowane do testowania buforowania. Aby uzyskać więcej informacji, zobacz Rozwiązywanie problemów.

Aby uzyskać więcej informacji, zobacz Buforowanie odpowiedzi w programie ASP.NET Core.

Buforowanie danych wyjściowych

Oprogramowanie pośredniczące buforowania danych wyjściowych umożliwia buforowanie odpowiedzi HTTP. Buforowanie danych wyjściowych różni się od buforowania odpowiedzi na następujące sposoby:

• Zachowanie buforowania można skonfigurować na serwerze.

  Zachowanie buforowania odpowiedzi jest definiowane przez nagłówki HTTP. Na przykład podczas odwiedzania witryny internetowej w przeglądarce Chrome lub Edge przeglądarka automatycznie wysyła Cache-control: max-age=0 nagłówek. Ten nagłówek skutecznie wyłącza buforowanie odpowiedzi, ponieważ serwer jest zgodny z instrukcjami dostarczonymi przez klienta. Dla każdego żądania jest zwracana nowa odpowiedź, nawet jeśli serwer ma nową odpowiedź w pamięci podręcznej. W przypadku buforowania danych wyjściowych klient nie zastępuje zachowania buforowania skonfigurowanego na serwerze.

• Nośnik magazynu pamięci podręcznej jest rozszerzalny.

  Pamięć jest używana domyślnie. Buforowanie odpowiedzi jest ograniczone do pamięci.

• Można programowo unieważnić wybrane wpisy pamięci podręcznej.

  Zależność buforowania odpowiedzi od nagłówków HTTP pozostawia kilka opcji unieważniania wpisów pamięci podręcznej.

• Blokowanie zasobów zmniejsza ryzyko stemplowania pamięci podręcznej i grzmiące stada.

  Sygnatura pamięci podręcznej występuje, gdy często używany wpis pamięci podręcznej jest odwoływane, a zbyt wiele żądań próbuje ponownie wypełniać ten sam wpis pamięci podręcznej w tym samym czasie. Stado thundering jest podobne: wybuch żądań dla tej samej odpowiedzi, która nie znajduje się jeszcze w wpisie pamięci podręcznej. Blokowanie zasobów gwarantuje, że wszystkie żądania dla danej odpowiedzi oczekują na pierwsze żądanie wypełnienia pamięci podręcznej. Buforowanie odpowiedzi nie ma funkcji blokowania zasobów.

• Zmiana pamięci podręcznej minimalizuje użycie przepustowości.

  Zmiana pamięci podręcznej oznacza, że serwer może zwrócić 304 Not Modified kod stanu HTTP zamiast buforowanej treści odpowiedzi. Ten kod stanu informuje klienta, że odpowiedź na żądanie nie zmienia się od tego, co zostało wcześniej odebrane. Buforowanie odpowiedzi nie powoduje ponownej zmiany pamięci podręcznej.

Aby uzyskać więcej informacji, zobacz Oprogramowanie pośredniczące buforowania danych wyjściowych w programie ASP.NET Core.

Pomocnik tagów pamięci podręcznej

Buforuj zawartość z widoku MVC lub Razor strony za pomocą pomocnika tagów pamięci podręcznej. Pomocnik tagów pamięci podręcznej używa buforowania w pamięci do przechowywania danych.

Aby uzyskać więcej informacji, zobacz Cache Tag Helper in ASP.NET Core MVC (Pomocnik tagów pamięci podręcznej w usłudze ASP.NET Core MVC).

Pomocnik tagów rozproszonej pamięci podręcznej

Buforuj zawartość z widoku MVC lub Razor strony w scenariuszach rozproszonych w chmurze lub farmie internetowej za pomocą pomocnika tagów rozproszonej pamięci podręcznej. Pomocnik tagów rozproszonej pamięci podręcznej używa programu SQL Server, Redis lub NCache do przechowywania danych.

Aby uzyskać więcej informacji, zobacz Distributed Cache Tag Helper in ASP.NET Core (Pomocnik tagów rozproszonej pamięci podręcznej w ASP.NET Core).