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 z użyciem powiązania sesji. Koligacja sesji jest również znana jako sticky sessions. Powiązanie sesji oznacza, że żądania od klienta są zawsze kierowane do tego samego serwera w celu przetworzenia.

Aby uzyskać więcej informacji, zobacz Buforowanie w pamięci w programie ASP.NET Core i Rozwiązywanie problemów z powiązaniem sesji bramy aplikacyjnej 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, takimi jak SQL Server, Redis i NCache.

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

Hybrydowa usługaCache

Interfejs API HybridCache wypełnia pewne luki w API IDistributedCache 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 do buforowania zarówno wewnątrz procesu, jak i poza procesem.

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

• Ochrona przed tratowaniem.

  Gwałtowna aktualizacja pamięci podręcznej występuje, gdy często używany wpis pamięci podręcznej zostaje unieważniony, a zbyt wiele żądań próbuje odtworzyć 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 serializacja.

  Serializacja jest konfigurowana w ramach rejestrowania usługi z obsługą serializatorów specyficznych dla rodzaju i uogólnionych za pomocą metod WithSerializer i WithSerializerFactory, poprzez wywołanie AddHybridCache. Domyślnie usługa obsługuje string i byte[] wewnętrznie, i używa System.Text.Json do wszystkiego innego. 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 zrobić to poprawnie, łącznie z takimi rzeczami, jak serializacja, za każdym razem. W scenariuszu „chybienia pamięci podręcznej” można trafić na wiele współbieżnych wątków, które wszystkie doświadczają chybienia, pobierają dane bazowe, serializują je i przesyłają te dane 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 dostarcza ochronę przed zatorami i inne funkcje, które IDistributedCache nie.

Zgodność

Biblioteka HybridCache obsługuje starsze platformy .NET aż do wersji .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
• propozycja interfejsu API hybrydowej pamięci podręcznej (dotnet/aspnetcore #54647)
• HybridCache kodu źródłowego

Buforowanie odpowiedzi

Middleware buforujące 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 HTTP, podobnie 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 dla publicznych żądań GET lub HEAD API od klientów, gdy 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, gdy odwiedzasz witrynę internetową za pomocą przeglądarki Chrome lub Edge, przeglądarka automatycznie wysyła nagłówek Cache-control: max-age=0. 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 niewiele opcji do unieważniania wpisów pamięci podręcznej.

• Blokowanie zasobów zmniejsza ryzyko szturmu na pamięć podręczną i zjawiska 'thundering herd'.

  na pamięć podręczną występuje, gdy często używany wpis pamięci podręcznej jest unieważniany, a zbyt wiele żądań próbuje ponownie wypełnić ten sam wpis pamięci podręcznej w tym samym czasie. Problem lawiny jest podobny: nagły wzrost żądań o tę samą odpowiedź, która nie jest jeszcze w zapisie w 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.

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

  Ponowna walidacja pamięci podręcznej oznacza, że serwer może zwrócić 304 Not Modified kod stanu HTTP zamiast zbuforowanej 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 Pośredniczące oprogramowanie do buforowania danych wyjściowych w 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 do tagów pamięci podręcznej rozproszonej

Buforuj zawartość widoku MVC lub Razor strony w scenariuszach rozproszonej chmury lub farmy internetowej przy użyciu pomocnika tagów dla 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).