Ereignisse
Power BI DataViz Weltmeisterschaften
14. Feb., 16 Uhr - 31. März, 16 Uhr
Mit 4 Chancen, ein Konferenzpaket zu gewinnen und es zum LIVE Grand Finale in Las Vegas zu machen
Weitere InformationenDieser Browser wird nicht mehr unterstützt.
Führen Sie ein Upgrade auf Microsoft Edge durch, um die neuesten Features, Sicherheitsupdates und den technischen Support zu nutzen.
Hinweis
Dies ist nicht die neueste Version dieses Artikels. Die aktuelle Version finden Sie in der .NET 9-Version dieses Artikels.
Warnung
Diese Version von ASP.NET Core wird nicht mehr unterstützt. Weitere Informationen finden Sie in der .NET- und .NET Core-Supportrichtlinie. Die aktuelle Version finden Sie in der .NET 9-Version dieses Artikels.
Wichtig
Diese Informationen beziehen sich auf ein Vorabversionsprodukt, das vor der kommerziellen Freigabe möglicherweise noch wesentlichen Änderungen unterliegt. Microsoft gibt keine Garantie, weder ausdrücklich noch impliziert, hinsichtlich der hier bereitgestellten Informationen.
Die aktuelle Version finden Sie in der .NET 9-Version dieses Artikels.
Von Rick Anderson und Tom Dykstra
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.
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.
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.
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.
Die HybridCache
-Bibliothek unterstützt ältere .NET-Runtimes bis zu .NET Framework 4.7.2 und .NET Standard 2.0.
Weitere Informationen finden Sie in den folgenden Ressourcen:
Für die Middleware zum Zwischenspeichern von Antworten gilt Folgendes:
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.
Weitere Informationen finden Sie unter Zwischenspeichern von Antworten in ASP.NET Core.
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.
Weitere Informationen finden Sie unter Ausgabezwischenspeicherungs-Middleware in ASP.NET Core.
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.
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.
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.
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.
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.
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.
Die HybridCache
-Bibliothek unterstützt ältere .NET-Runtimes bis zu .NET Framework 4.7.2 und .NET Standard 2.0.
Weitere Informationen finden Sie in den folgenden Ressourcen:
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.
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.
Für die Middleware zum Zwischenspeichern von Antworten gilt Folgendes:
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.
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.
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.
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.
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.
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.
Die HybridCache
-Bibliothek unterstützt ältere .NET-Runtimes bis zu .NET Framework 4.7.2 und .NET Standard 2.0.
Weitere Informationen finden Sie in den folgenden Ressourcen:
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.
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.
Für die Middleware zum Zwischenspeichern von Antworten gilt Folgendes:
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.
Die Ausgabezwischenspeicherung ist in .NET 7 und höher verfügbar.
Feedback zu ASP.NET Core
ASP.NET Core ist ein Open Source-Projekt. Wählen Sie einen Link aus, um Feedback zu geben:
Ereignisse
Power BI DataViz Weltmeisterschaften
14. Feb., 16 Uhr - 31. März, 16 Uhr
Mit 4 Chancen, ein Konferenzpaket zu gewinnen und es zum LIVE Grand Finale in Las Vegas zu machen
Weitere InformationenTraining
Modul
Verbessern der Leistung mit einem Cache in einem .NET Aspire-Projekt - Training
In diesem Modul erfahren Sie mehr über Caches in einer cloudnativen .NET Aspire-App und wie Sie diese verwenden können, um die Leistung Ihrer Microservices zu optimieren.
Zertifizierung
Microsoft Certified: Azure Cosmos DB Developer Specialty - Certifications
Schreiben Sie effiziente Abfragen, erstellen Sie Indizierungsrichtlinien, verwalten Sie und Sie Ressourcen in der SQL-API und im SDK mit Microsoft Azure Cosmos DB bereit.
Dokumentation
Middleware für die Ausgabezwischenspeicherung in ASP.NET Core
Erfahren Sie, wie Sie Middleware für die Ausgabezwischenspeicherung in ASP.NET Core konfigurieren und verwenden.
HybridCache-Bibliothek in ASP.NET Core
Erfahren Sie, wie Sie die HybridCache-Bibliothek in ASP.NET Core verwenden.
Verteiltes Zwischenspeichern in ASP.NET Core
Erfahren Sie, wie Sie verteilten ASP.NET Core-Cache verwenden können, um die Leistung und Skalierbarkeit einer App zu verbessern, insbesondere in einer Cloud- oder Serverfarmumgebung.