Übersicht über die Zwischenspeicherung in ASP.NET Core

Von Rick Anderson und Tom Dykstra

In-Memory-Caching

Die In-Memory-Zwischenspeicherung verwendet Serverarbeitsspeicher zur Aufbewahrung zwischengespeicherter Daten. Diese Art des Zwischenspeicherns eignet sich für einen einzelnen Server oder für mehrere Server mit Sitzungsaffinität. Die Sitzungsaffinität wird auch als Sticky Sessions bezeichnet. Sitzungsaffinität bedeutet, dass die Anforderungen von einem Client immer an denselben Server zur Verarbeitung weitergeleitet werden.

Weitere Informationen finden Sie unter In-Memory-Zwischenspeicherung in ASP.NET Core und unter Behandeln von Problemen mit der Azure Application Gateway-Sitzungsaffinität.

Verteilter Cache

Verwenden Sie einen verteilten Cache, um Daten zu speichern, wenn die App in einer Cloud oder Serverfarm gehostet wird. Der Cache wird von den Servern, die Anforderungen verarbeiten, gemeinsam genutzt. Ein Client kann eine Anforderung übermitteln, die von einem beliebigen Server in der Gruppe verarbeitet wird, wenn zwischengespeicherte Daten für den Client verfügbar sind. ASP.NET Core funktioniert mit verteilten Caches von SQL Server, Redis und NCache.

Weitere Informationen finden Sie unter Verteiltes Zwischenspeichern in ASP.NET Core.

HybridCache

Die HybridCache-API überbrückt einige Lücken in den IDistributedCache und IMemoryCache-APIs. HybridCache ist eine abstrakte Klasse mit einer Standardimplementierung, welche die meisten Aspekte des Speicherns im Cache und abrufen aus dem Cache behandelt.

Features

HybridCache verfügt über die folgenden Features, welche die anderen APIs nicht haben:

• Eine einheitliche API für die In-Process- und Out-of-Process-Zwischenspeicherung.

  HybridCache ist als Drop-In-Ersatz für vorhandene IDistributedCache- und IMemoryCache-Nutzung konzipiert und bietet eine einfache API zum Hinzufügen von neuem Zwischenspeicherungscode. Wenn die App über eine IDistributedCache-Implementierung verfügt, verwendet der HybridCache-Dienst sie für die sekundäre Zwischenspeicherung. Diese zweistufige Zwischenspeicherungsstrategie ermöglicht HybridCache die Geschwindigkeit eines Speichercaches und die Haltbarkeit eines verteilten oder persistenten Caches.

• Stampede-Schutz.

  Cache Stampede tritt auf, wenn ein häufig verwendeter Cacheeintrag widerrufen wird und zu viele Anforderungen versuchen, denselben Cacheeintrag gleichzeitig neu aufzufüllen. HybridCache kombiniert gleichzeitige Vorgänge, um sicherzustellen, dass alle Anforderungen für eine bestimmte Antwort auf die erste Anforderung warten, um den Cache aufzufüllen.

• Konfigurierbare Serialisierung.

  Die Serialisierung wird als Teil der Registrierung des Diensts konfiguriert, wobei typspezifische und generalisierte Serialisierer über die WithSerializer- und WithSerializerFactory-Methoden, verkettet vom AddHybridCache-Aufruf, unterstützt werden. Standardmäßig verarbeitet der Dienst string und byte[] intern und verwendet System.Text.Json für alles andere. Er kann für andere Typen von Serialisierern konfiguriert werden, z. B. Protobuf oder XML.

Um die relative Einfachheit der HybridCache-API anzuzeigen, vergleichen Sie Code, den sie verwendet, mit Code, der IDistributedCache verwendet. Hier sehen Sie ein Beispiel dafür, wie die Verwendung von IDistributedCache aussieht:

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)
    { /* ... */ }
}

Das ist viel Arbeit, um jedes Mal richtig zu liegen, einschließlich Dinge wie Serialisierung. Und im Szenario „Cachefehler“ könnten Sie mit mehreren gleichzeitigen Threads enden, die alle einen Cachefehler erhalten, alle zugrunde liegenden Daten abrufen, serialisieren und alle diese Daten an den Cache senden.

Hier sehen Sie den entsprechenden Code mit 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
        );
    }
}

Der Code ist einfacher und die Bibliothek bietet Stampede-Schutz und andere Features, die IDistributedCache nicht hat.

Kompatibilität

Die Bibliothek unterstützt ältere .NET-Runtimes bis zu .NET Framework 4.7.2 und .NET Standard 2.0.

Zusätzliche Ressourcen

Weitere Informationen finden Sie in den folgenden Ressourcen:

• HybridCache-Bibliothek in ASP.NET Core
• GitHub-Problem dotnet/aspnetcore 54647
• HybridCache-Quellcode

Cache-Taghilfsprogramm

Speichern Sie den Inhalt aus einer MVC-Ansicht oder einer Razor Page-Instanz mit dem Cache-Taghilfsprogramm zwischen. Das Cache-Taghilfsprogramm verwendet die In-Memory-Zwischenspeicherung zum Speichern von Daten.

Weitere Informationen finden Sie unter Cache-Taghilfsprogramm im ASP.NET Core MVC.

Taghilfsprogramm für verteilten Cache

Speichern Sie den Inhalt aus einer MVC-Ansicht oder einer Razor Page-Instanz in verteilten Cloud- oder Webfarmszenarien mit dem Taghilfsprogramm für verteilten Cache zwischen. Das Taghilfsprogramm für verteilten Cache verwendet SQL Server, Redis oder NCache zum Speichern von Daten.

Weitere Informationen finden Sie unter Taghilfsprogramm für verteilten Cache in ASP.NET Core.

Zwischenspeichern von Antworten

Für die Middleware zum Zwischenspeichern von Antworten gilt Folgendes:

• Ermöglicht das Zwischenspeichern von Serverantworten basierend auf HTTP-Cacheheadern. Implementiert die standardmäßige HTTP-Zwischenspeicherungssemantik. Führt die Zwischenspeicherung basierend auf HTTP-Cacheheadern durch – genauso wie Proxys.
• Ist in der Regel nicht vorteilhaft für Benutzeroberflächen-Apps wie Razor Pages, da Browser im Allgemeinen Anforderungsheader festlegen, die das Zwischenspeichern verhindern. Benutzeroberflächen-Apps profitieren von der Ausgabezwischenspeicherung, die in ASP.NET Core 7.0 und höher verfügbar ist. Bei der Ausgabezwischenspeicherung entscheidet die Konfiguration unabhängig von HTTP-Headern, was zwischengespeichert werden soll.
• Dies kann bei öffentlichen GET- oder HEAD API-Anforderungen von Clients von Vorteil sein, wenn die Bedingungen für die Zwischenspeicherung erfüllt sind.

Verwenden Sie zum Testen der Antwortzwischenspeicherung Fiddler oder ein anderes Tool, das Anforderungsheader explizit festlegen kann. Beim Testen der Zwischenspeicherung wird das explizite Festlegen von Headern bevorzugt. Weitere Informationen finden Sie unter Problembehandlung.

Ausgabezwischenspeicherung

Die Middleware für die Ausgabezwischenspeicherung ermöglicht das Zwischenspeichern von HTTP-Antworten. Die Ausgabezwischenspeicherung unterscheidet sich auf folgende Weise vom Zwischenspeichern von Antworten:

• Das Zwischenspeicherungsverhalten kann auf dem Server konfiguriert werden.

  Das Verhalten der Antwortzwischenspeicherung wird durch HTTP-Header definiert. Wenn Sie beispielsweise eine Website über Chrome oder Edge besuchen, sendet der Browser automatisch einen Cache-control: max-age=0-Header. Dieser Header deaktiviert effektiv die Antwortzwischenspeicherung, da der Server die vom Client angegebenen Anweisungen befolgt. Für jede Anforderung wird auch dann eine neue Antwort zurückgegeben, wenn der Server über eine aktuelle zwischengespeicherte Antwort verfügt. Bei der Ausgabezwischenspeicherung überschreibt der Client nicht das Zwischenspeicherungsverhalten, das Sie auf dem Server konfigurieren.

• Das Cachespeichermedium ist erweiterbar.

  Der Arbeitsspeicher wird standardmäßig verwendet. Die Antwortzwischenspeicherung ist auf den Arbeitsspeicher beschränkt.

• Sie können ausgewählte Cacheeinträge programmgesteuert als ungültig festlegen.

  Die Abhängigkeit der Antwortzwischenspeicherung von HTTP-Headern lässt Ihnen nur wenige Optionen zum Aufheben der Gültigkeit von Cacheeinträgen.

• Die Ressourcensperrung verringert das Risiko von Cache Stampede und Thundering Herd Problem.

  Cache Stampede tritt auf, wenn ein häufig verwendeter Cacheeintrag widerrufen wird und zu viele Anforderungen versuchen, denselben Cacheeintrag gleichzeitig neu aufzufüllen. Thundering Herd ist ähnlich: eine Flut von Anforderungen für dieselbe Antwort, die sich noch nicht in einem Cacheeintrag befindet. Die Ressourcensperre sorgt dafür, dass alle Anforderungen für eine bestimmte Antwort auf die erste Anforderung warten, um den Cache zu füllen. Die Antwortzwischenspeicherung verfügt über kein Feature zum Sperren von Ressourcen.

• Die erneute Cacheüberprüfung minimiert die Bandbreitennutzung.

  Erneute Cacheüberprüfung bedeutet, dass der Server anstelle eines zwischengespeicherten Antworttexts einen 304 Not Modified-HTTP-Statuscode zurückgeben kann. Dieser Statuscode informiert den Client darüber, dass die Antwort auf die Anforderung mit der zuvor empfangenen Antwort identisch ist. Bei der Antwortzwischenspeicherung wird keine erneute Cacheüberprüfung durchgeführt.