Wiederholungsanleitung für Azure-Dienste

Artikel
06/13/2023

Die meisten Azure-Dienste und Client-SDKs enthalten einen Wiederholungsmechanismus. Diese unterscheiden sich jedoch, da jeder Dienst unterschiedliche Merkmale und Anforderungen hat und somit jeder Wiederholungsmechanismus für einen bestimmten Dienst optimiert ist. Dieses Handbuch fasst die Wiederholungsmechanismusfunktionen für die meisten Azure-Dienste zusammen und enthält Informationen, mit denen Sie die Wiederholungsmechanismus für diesen Dienst verwenden, anpassen oder erweitern können.

Allgemeine Anweisungen zum Behandeln von vorübergehenden Fehlern und für Wiederholungsverbindungen und Operationen für Dienste und Ressourcen finden Sie unter Wiederholungsanleitung.

In der folgende Tabelle werden die Wiederholungsfunktionen für die in dieser Anleitung beschriebenen Azure-Dienste zusammengefasst.

Service	Wiederholungsfunktionen	Richtlinienkonfiguration	Umfang	Telemetriefunktionen
Microsoft Entra ID	Nativ in MSAL-Bibliothek	Eingebettet in MSAL-Bibliothek	Intern	Keine
Azure Cosmos DB	Systemeigen im Dienst	Nicht konfigurierbar	Global	TraceSource
Data Lake Store	Systemeigen in Client	Nicht konfigurierbar	Einzelne Vorgänge	Keine
Event Hubs	Systemeigen in Client	Programmgesteuert	Client	Keine
IoT Hub	Nativ im Client SDK	Programmgesteuert	Client	Keine
Azure Cache for Redis	Systemeigen in Client	Programmgesteuert	Client	TextWriter
Search	Systemeigen in Client	Programmgesteuert	Client	Ereignisablaufverfolgung für Windows (ETW) oder benutzerdefiniert
Service Bus	Systemeigen in Client	Programmgesteuert	Namespace-Manager, Messaging Factory und Client	ETW
Service Fabric	Systemeigen in Client	Programmgesteuert	Client	Keine
SQL-Datenbank mit ADO.NET	Polly	Deklarativ und programmatisch	Einzelne Anweisungen oder Codeblöcke	Benutzerdefiniert
SQL-Datenbank mit Entity Framework	Systemeigen in Client	Programmgesteuert	Global pro AppDomain	Keine
SQL-Datenbank mit Entity Framework Core	Systemeigen in Client	Programmgesteuert	Global pro AppDomain	Keine
Storage	Systemeigen in Client	Programmgesteuert	Clientvorgänge und einzelne Vorgänge	TraceSource

Hinweis

Für die meisten der integrierten Azure-Mechanismen gibt es derzeit keine Möglichkeit, unterschiedliche Wiederholungsrichtlinien für verschiedene Arten von Fehlern oder Ausnahmen anzuwenden. Konfigurieren Sie eine Richtlinie mit optimalem Leistungs- und Verfügbarkeitsdurchschnitt. Eine Möglichkeit zur Optimierung der Richtlinie ist die Analyse von Protokolldateien, um den Typ der vorübergehenden Fehler zu bestimmen, die auftreten.

Microsoft Entra ID

Microsoft Entra ID ist eine umfassende Cloudlösung für die Identitäts- und Zugriffsverwaltung, die zentrale Verzeichnisdienste, eine erweiterte Identitätsgovernance, Sicherheit und Zugriffsverwaltung von Anwendungen kombiniert. Microsoft Entra ID bietet Entwickler*innen auf der Grundlage von zentralen Richtlinien und Regeln auch eine Plattform für die Identitätsverwaltung zur Bereitstellung einer Zugriffssteuerung für deren Anwendungen.

Hinweis

Eine Anleitung zu Wiederholungen für Endpunkte der verwalteten Dienstidentität finden Sie unter Verwenden der verwalteten Dienstidentität (Managed Service Identity, MSI) eines virtuellen Azure-Computers für den Tokenabruf.

Wiederholungsmechanismus

In der Microsoft-Authentifizierungsbibliothek (MSAL) ist ein integrierter Wiederholungsmechanismus für Microsoft Entra ID enthalten. Zur Vermeidung unerwarteter Sperrungen empfehlen wir, für Drittanbieterbibliotheken und -anwendungscode keine Wiederholungsversuche zum Herstellen von fehlgeschlagenen Verbindungen durchzuführen, sondern die Verarbeitung von Wiederholungsversuchen MSAL zu überlassen.

Gebrauchsanleitung Wiederholungen

Berücksichtigen Sie bei Verwendung von Microsoft Entra ID die folgenden Richtlinien:

Verwenden Sie nach Möglichkeit die MSAL-Bibliothek und die integrierte Unterstützung für Wiederholungsversuche.
Wenn Sie die REST-API für Microsoft Entra ID verwenden, wiederholen Sie den Vorgang, wenn der Ergebniscode 429 (Zu viele Anforderungen) lautet oder das Ergebnis ein Fehler im Bereich 5xx ist. Bei anderen Fehlern den Vorgang nicht wiederholen.
Wiederholen Sie bei Fehlern des Typs 429 den Vorgang nach der im Header Retry-After angegebenen Zeit.
Verwenden Sie bei Fehlern des Typs 5xx exponentielles Backoff mit dem ersten Wiederholungsversuch mindestens 5 Sekunden nach der Antwort.
Wiederholungsversuche sind auf die Fehler 429 und 5xx beschränkt.

Nächste Schritte

Microsoft Authentication Library (MSAL)

Azure Cosmos DB

Azure Cosmos DB ist eine vollständig verwaltete Datenbank mit mehreren Modellen, die schemalose JSON-Daten unterstützt. Sie bietet konfigurierbare und zuverlässige Leistung, systemeigene JavaScript-Transaktionsverarbeitung und ist für die Cloud mit elastischer Skalierung konzipiert.

Wiederholungsmechanismus

Von den Azure Cosmos DB SDKs werden Vorgänge bei bestimmten Fehlerbedingungen automatisch wiederholt, und Benutzeranwendungen sollten nach Möglichkeit über eigene Wiederholungsrichtlinien verfügen. Eine vollständige Liste mit Fehlerbedingungen und Situationen, in denen Vorgänge wiederholt werden sollten, finden Sie im Leitfaden zum Entwerfen resilienter Anwendungen mit Azure Cosmos DB SDKs.

Telemetrie

Abhängig von der Sprache Ihrer Anwendung werden Diagnose und Telemetrie als Protokolle oder höher gestufte Eigenschaften für die Vorgangsantworten verfügbar gemacht. Weitere Informationen finden Sie unter Diagnose und Fehlerbehebung bei langsamen Anforderungen in Azure Cosmos DB .NET SDK sowie unter Behandeln von Problemen bei der Verwendung des Azure Cosmos DB Java SDK v4 mit der API für NoSQL-Konten (jeweils im Abschnitt „Erfassen der Diagnose“).

Data Lake Store

Mit Data Lake Storage Gen2 wird Azure Storage zur Grundlage für das Erstellen von Enterprise Data Lakes in Azure. Data Lake Storage Gen2 ermöglicht Ihnen die einfache Verwaltung großer Datenmengen.

Die Clientbibliothek „Azure.Storage.Files.DataLake“ umfasst alle erforderlichen Funktionen, die Entwickler, wissenschaftliche Fachkräfte für Daten und Analysten benötigen, um Daten problemlos speichern zu können, und zwar unabhängig von der Größe, vom Format und von der Geschwindigkeit der Daten. Darüber hinaus können die Daten mit Data Lake Store auf verschiedene Art, auf verschiedenen Plattformen und unter Verwendung verschiedener Sprachen verarbeitet und analysiert werden.

Wiederholungsmechanismus

Mit dem DataLakeServiceClient können Sie Azure Data Lake-Dienstressourcen und -Dateisysteme bearbeiten. Das Speicherkonto stellt den Namespace der obersten Ebene für den Data Lake-Dienst bereit. Wenn Sie den Client erstellen, können Sie die Clientkonfigurationsoptionen für die Verbindung mit dem Azure Data Lake-Dienst (DataLakeClientOptions) bereitstellen. DataLakeClientOptions enthält eine RETRY-Eigenschaft (geerbt von Azure.Core.ClientOptions), die konfiguriert werden kann (RetryOptions-Klasse).

Telemetrie

Die Überwachung von Verbrauch und Leistung von Azure Storage ist ein wichtiger Bestandteil der Operationalisierung Ihres Diensts. Beispiele hierfür sind häufig ausgeführte Vorgänge, Vorgänge mit hoher Latenz oder Vorgänge, die eine dienstseitige Drosselung zur Folge haben.

Alle Telemetriedaten für Ihr Speicherkonto sind über Azure Storage-Protokolle in Azure Monitor verfügbar. Mit dieser Funktion wird das Speicherkonto in Log Analytics und Event Hubs integriert. Gleichzeitig können Sie Protokolle in einem anderen Speicherkonto archivieren. Die vollständige Liste der Metriken und Ressourcenprotokolle und das zugehörige Schema finden Sie unter Überwachen von Daten in Azure Storage – Referenz.

Event Hubs

Azure Event Hubs ist ein hyperskalierbarer Dienst für die Erfassung von Telemetriedaten, der Millionen von Ereignissen sammelt, transformiert und speichert.

Wiederholungsmechanismus

Das Wiederholungsverhalten in der Azure Event Hubs-Clientbibliothek wird von der RetryPolicy-Eigenschaft in der EventHubClient-Klasse gesteuert. Die Standardrichtlinie führt Wiederholungsversuche mit exponentiell ansteigender Wartezeit durch, wenn Azure Event Hubs eine vorübergehende Ausnahme vom Typ EventHubsException oder OperationCanceledException zurückgibt. Bei der standardmäßigen Wiederholungsrichtlinie für Event Hubs werden bis zu neun Wiederholungsversuche mit einer exponentiellen Backoffdauer von bis zu 30 Sekunden durchgeführt.

Beispiel

EventHubClient client = EventHubClient.CreateWithManagedIdentity(new Uri("sb://full_namespace_url", "entity_path");
client.RetryPolicy = RetryPolicy.Default;

Nächste Schritte

Azure Event Hubs-Clientbibliothek für .NET

IoT Hub

Azure IoT Hub ist ein Dienst zum Verbinden, Überwachen und Verwalten von Geräten für die Entwicklung von IoT-Anwendungen (Internet of Things, Internet der Dinge).

Wiederholungsmechanismus

Mit dem Azure IoT-Geräte-SDK können Fehler im Netzwerk, im Protokoll oder in der Anwendung ermittelt werden. Basierend auf dem Fehlertyp überprüft das SDK, ob eine Wiederholung erforderlich ist. Ist der Fehler behebbar, beginnt das SDK unter Verwendung der Wiederholungsrichtlinie mit der Wiederholung.

Die standardmäßige Wiederholungsrichtlinie ist exponentielles Backoff mit zufälligem Jitter, sie kann jedoch konfiguriert werden.

Richtlinienkonfiguration

Die Richtlinienkonfiguration unterscheidet sich je nach Sprache. Weitere Informationen finden Sie unter APIs für Wiederholungsrichtlinien.

Nächste Schritte

Azure Cache for Redis

Azure Cache for Redis ist ein Dienst für schnellen Datenzugriff und Caching mit niedriger Latenz, der auf dem beliebten Open-Source-Cache Redis basiert. Er ist sicher, von Microsoft verwaltet und von jeder Anwendung in Azure aus zugänglich.

Die Anleitung in diesem Abschnitt beruht auf der Verwendung des StackExchange.Redis-Clients für den Zugriff auf den Cache. Eine Liste der anderer geeigneter Clients finden Sie auf der Redis-Website, diese haben möglicherweise unterschiedliche Wiederholungsmechanismen.

Der StackExchange.Redis-Client verwendet Multiplex über eine einzige Verbindung. Die empfohlene Verwendung ist das Erstellen einer Instanz des Clients beim Starten der Anwendung und die Verwendung dieser Instanz für alle Vorgänge im Cache. Aus diesem Grund wird die Verbindung mit dem Cache nur einmal hergestellt und die Anleitungen in diesem Abschnitt beziehen sich auf die Wiederholungsrichtlinie für die anfängliche Verbindung - und nicht für jeden Vorgang, der auf den Cache zugreift.

Wiederholungsmechanismus

Der StackExchange.Redis-Client verwendet eine Verbindungs-Manager-Klasse, die über eine Reihe von Optionen konfiguriert ist, z. B.:

ConnectRetry: Die Anzahl, wie häufig erneut versucht wird, eine fehlgeschlagene Verbindung mit dem Cache herzustellen.
ReconnectRetryPolicy: Die Wiederholungsstrategie, die verwendet werden soll.
ConnectTimeout: Die maximale Wartezeit in Millisekunden.

Richtlinienkonfiguration

Wiederholungsrichtlinien werden programmgesteuert durch Festlegen der Optionen für den Client konfiguriert, bevor eine Verbindung mit dem Cache hergestellt wird. Dies kann durch das Erstellen einer Instanz der ConfigurationOptions-Klasse, das Auffüllen ihrer Eigenschaften und die Übergabe an die Connect-Methode erreicht werden.

Die integrierten Klassen unterstützen die lineare (konstante) Verzögerung und exponentiell ansteigende Wartezeiten mit zufälligen Wiederholungsintervallen. Sie können auch eine benutzerdefinierte Wiederholungsrichtlinie erstellen, indem Sie die IReconnectRetryPolicy-Schnittstelle implementieren.

Im folgenden Beispiel wird eine Wiederholungsstrategie mit exponentiell ansteigender Wartezeit konfiguriert.

var deltaBackOffInMilliseconds = TimeSpan.FromSeconds(5).TotalMilliseconds;
var maxDeltaBackOffInMilliseconds = TimeSpan.FromSeconds(20).TotalMilliseconds;
var options = new ConfigurationOptions
{
    EndPoints = {"localhost"},
    ConnectRetry = 3,
    ReconnectRetryPolicy = new ExponentialRetry(deltaBackOffInMilliseconds, maxDeltaBackOffInMilliseconds),
    ConnectTimeout = 2000
};
ConnectionMultiplexer redis = ConnectionMultiplexer.Connect(options, writer);

Alternativ können Sie die Optionen als Zeichenfolge angeben und diese an die Connect Methode übergeben. Die ReconnectRetryPolicy-Eigenschaft kann nicht auf diese Weise festgelegt werden, sondern nur per Code.

var options = "localhost,connectRetry=3,connectTimeout=2000";
ConnectionMultiplexer redis = ConnectionMultiplexer.Connect(options, writer);

Es ist auch möglich, Optionen direkt beim Herstellen der Verbindung mit dem Cache anzugeben.

var conn = ConnectionMultiplexer.Connect("redis0:6380,redis1:6380,connectRetry=3");

Weitere Informationen finden Sie unter Configuration (Konfiguration) in der StackExchange.Redis-Dokumentation.

Die folgende Tabelle zeigt die Standardeinstellungen für die integrierte Wiederholungsrichtlinie.

Context	Einstellung	Standardwert (v 1.2.2)	Bedeutung
ConfigurationOptions	ConnectRetry ConnectTimeout SyncTimeout ReconnectRetryPolicy	3 Maximal 5000 ms plus SyncTimeout 1000 LinearRetry 5000 ms	Die Anzahl der Wiederholungen von Verbindungsversuchen während des Erstverbindungsvorgangs. Zeitlimit (ms) für Verbindungen. Keine Verzögerung zwischen den Wiederholungsversuchen. Zeit (ms), um synchrone Vorgänge zu ermöglichen. Wiederholung jeweils nach 5000 ms.

Hinweis

Für synchrone Vorgänge kann SyncTimeout einen Beitrag zur End-to-End-Wartezeit leisten, aber wenn der Wert zu niedrig festgelegt wird, kann es zu übermäßigen Zeitüberschreitungen kommen. Weitere Informationen finden Sie unter Problembehandlung für Azure Cache for Redis. Im Allgemeinen ist es ratsam, die Verwendung von synchronen Vorgängen zu vermeiden und stattdessen asynchrone Vorgänge zu verwenden. Weitere Informationen finden Sie unter Pipelines und Multiplexers.

Gebrauchsanleitung Wiederholungen

Berücksichtigen Sie bei Verwendung von Azure Cache for Redis die folgenden Richtlinien:

Der StackExchange Redis-Client verwaltet seine eigene Wiederholungen, aber nur beim Herstellen einer Verbindung mit dem Cache beim ersten Starten der Anwendung. Sie können das Verbindungstimeout, die Anzahl von Wiederholungsversuchen und die Dauer zwischen den Wiederholungen zur Herstellung dieser Verbindung konfigurieren, aber die Wiederholungsrichtlinie gilt nicht für Vorgänge für den Cache.
Anstatt eine große Anzahl von Wiederholungsversuchen zu verwenden, sollten Sie auf die ursprüngliche Datenquelle zurückgreifen.

Telemetrie

Sie können Informationen zu Verbindungen (aber nicht für andere Vorgänge) mit einem TextWritersammeln.

var writer = new StringWriter();
ConnectionMultiplexer redis = ConnectionMultiplexer.Connect(options, writer);

Ein Beispiel für die dadurch generierte Ausgabe ist unten dargestellt.

localhost:6379,connectTimeout=2000,connectRetry=3
1 unique nodes specified
Requesting tie-break from localhost:6379 > __Booksleeve_TieBreak...
Allowing endpoints 00:00:02 to respond...
localhost:6379 faulted: SocketFailure on PING
localhost:6379 failed to nominate (Faulted)
> UnableToResolvePhysicalConnection on GET
No masters detected
localhost:6379: Standalone v2.0.0, master; keep-alive: 00:01:00; int: Connecting; sub: Connecting; not in use: DidNotRespond
localhost:6379: int ops=0, qu=0, qs=0, qc=1, wr=0, sync=1, socks=2; sub ops=0, qu=0, qs=0, qc=0, wr=0, socks=2
Circular op-count snapshot; int: 0 (0.00 ops/s; spans 10s); sub: 0 (0.00 ops/s; spans 10s)
Sync timeouts: 0; fire and forget: 0; last heartbeat: -1s ago
resetting failing connections to retry...
retrying; attempts left: 2...
...

Beispiele

Im folgenden Codebeispiel wird eine konstante (lineare) Verzögerung zwischen Wiederholungsversuchen konfiguriert, wenn der StackExchange.Redis-Client initialisiert wird. In diesem Beispiel wird veranschaulicht, wie die Konfiguration mit einer ConfigurationOptions-Instanz festgelegt wird.

using System;
using System.Collections.Generic;
using System.IO;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
using StackExchange.Redis;

namespace RetryCodeSamples
{
    class CacheRedisCodeSamples
    {
        public async static Task Samples()
        {
            var writer = new StringWriter();
            {
                try
                {
                    var retryTimeInMilliseconds = TimeSpan.FromSeconds(4).TotalMilliseconds; // delay between retries

                    // Using object-based configuration.
                    var options = new ConfigurationOptions
                                        {
                                            EndPoints = { "localhost" },
                                            ConnectRetry = 3,
                                            ReconnectRetryPolicy = new LinearRetry(retryTimeInMilliseconds)
                                        };
                    ConnectionMultiplexer redis = ConnectionMultiplexer.Connect(options, writer);

                    // Store a reference to the multiplexer for use in the application.
                }
                catch
                {
                    Console.WriteLine(writer.ToString());
                    throw;
                }
            }
        }
    }
}

Im nächsten Beispiel wird die Konfiguration durch Angeben der Optionen als Zeichenfolge festgelegt. Das Verbindungstimeout ist der maximale Zeitraum für das Warten auf die Verbindungsherstellung mit dem Cache und nicht die Verzögerung zwischen Wiederholungsversuchen. Die ReconnectRetryPolicy-Eigenschaft kann nur per Code festgelegt werden.

using System.Collections.Generic;
using System.IO;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
using StackExchange.Redis;

namespace RetryCodeSamples
{
    class CacheRedisCodeSamples
    {
        public async static Task Samples()
        {
            var writer = new StringWriter();
            {
                try
                {
                    // Using string-based configuration.
                    var options = "localhost,connectRetry=3,connectTimeout=2000";
                    ConnectionMultiplexer redis = ConnectionMultiplexer.Connect(options, writer);

                    // Store a reference to the multiplexer for use in the application.
                }
                catch
                {
                    Console.WriteLine(writer.ToString());
                    throw;
                }
            }
        }
    }
}

Weitere Beispiele finden Sie unter Konfiguration auf der Projektwebsite.

Nächste Schritte

Redis-Website

Azure Search

Azure Search kann dafür verwendet werden, nützliche und anspruchsvolle Suchfunktionen zu einer Website oder Anwendung hinzuzufügen, Suchergebnisse schnell und einfach zu optimieren und umfassende und fein abgestimmte Rangmodelle zu erstellen.

Wiederholungsmechanismus

Azure SDK für .NET enthält eine Azure.Search.Documents-Clientbibliothek des Azure SDK-Teams, die funktional der vorherigen Clientbibliothek Microsoft.Azure.Search entspricht.

Das Wiederholungsverhalten in Microsoft.Azure.Search wird durch die SetRetryPolicy-Methode in den Klassen SearchServiceClient und SearchIndexClient gesteuert. Bei der Standardrichtlinie werden Wiederholungsversuche mit exponentiellem Backoff (exponentiell ansteigende Wartezeiten) durchgeführt, wenn Azure Search eine 5xx- oder 408-Antwort (Anforderungstimeout) zurückgibt.

Das Wiederholungsverhalten in Azure.Search.Documents wird durch SearchClientOptions (Teil des SearchClient-Konstruktors) in der Retry-Eigenschaft gesteuert, die zur Klasse Azure.Core.RetryOptions gehört (in der alle Konfigurationen verfügbar sind).

Telemetrie

Nachverfolgung mit ETW oder per Registrierung eines benutzerdefinierten Ablaufverfolgungsanbieters. Weitere Informationen finden Sie in der AutoRest-Dokumentation.

Service Bus

Service Bus ist eine Cloud Messaging-Plattform, die losen gekoppelten Nachrichtenaustausch mit verbesserter Skalierbarkeit und Stabilität für die Komponenten einer Anwendung bietet, egal ob in der Cloud oder lokal gehostet.

Wiederholungsmechanismus

Der Namespace und einige Konfigurationsdetails sind davon abhängig, welches Service Bus-Client-SDK-Paket verwendet wird:

Paket	BESCHREIBUNG	Namespace
Azure.Messaging.ServiceBus	Azure Service Bus-Clientbibliothek für .NET	`Azure.Messaging.ServiceBus`
WindowsAzure.ServiceBus	Bei diesem Paket handelt es sich um die ältere Service Bus-Clientbibliothek. Hierfür ist .NET Framework 4.5.2 erforderlich.	`Microsoft.Azure.ServiceBus`

Gebrauchsanleitung Wiederholungen

Die ServiceBusRetryOptions-Eigenschaft gibt die Wiederholungsoptionen für das ServiceBusClient-Objekt an:

Einstellung	Standardwert	Bedeutung
CustomRetryPolicy		Eine benutzerdefinierte Wiederholungsrichtlinie, die anstelle der einzelnen Optionswerte verwendet werden soll.
Verzögern	0,8 Sekunden	Die Verzögerung zwischen Wiederholungsversuchen für einen festen Ansatz oder die Verzögerung, auf der Berechnungen für einen backoffbasierten Ansatz basieren.
MaxDelay	60 Sekunden	Die maximal zulässige Verzögerung zwischen Wiederholungsversuchen.
MaxRetries	3	Die maximale Anzahl von Wiederholungsversuchen, bevor der zugeordnete Vorgang als fehlgeschlagen angesehen wird
Mode	Exponentiell	Die Methode, die zum Berechnen von Wiederholungsverzögerungen verwendet werden soll
TryTimeout	60 Sekunden	Die maximale Dauer, die unabhängig davon, ob der erste Versuch oder ein Wiederholungsversuch durchgeführt wird, auf den Abschluss eines einzelnen Versuchs gewartet werden soll.

Legen Sie die Mode-Eigenschaft fest, um serviceBusRetryMode mit einem der folgenden Werte zu konfigurieren:

Eigenschaft	Wert	BESCHREIBUNG
Exponentiell	1	Wiederholungsversuche werden auf Basis einer Backoffstrategie verzögert, wobei jeder Versuch die Wartezeit vor einem neuen Versuch erhöht.
Fest	0	Wiederholungsversuche erfolgen in festen Intervallen. Die Dauer der Verzögerungen ist konsistent.

Beispiel:

using Azure.Identity;
using Azure.Messaging.ServiceBus;

string namespace = "<namespace>";
string queueName = "<queue_name>";

// Because ServiceBusClient implements IAsyncDisposable, we'll create it
// with "await using" so that it is automatically disposed for us.
var options = new ServiceBusClientOptions();
options.RetryOptions = new ServiceBusRetryOptions
{
    Delay = TimeSpan.FromSeconds(10),
    MaxDelay = TimeSpan.FromSeconds(30),
    Mode = ServiceBusRetryMode.Exponential,
    MaxRetries = 3,
};
await using var client = new ServiceBusClient(namespace, new DefaultAzureCredential(), options);

Telemetrie

Service Bus sammelt die gleichen Arten von Überwachungsdaten wie andere Azure-Ressourcen. Die Überwachung von Azure Service Bus ist mit Azure Monitor möglich.

Sie haben auch verschiedene Optionen zum Senden von Telemetriedaten mit den .NET-Clientbibliotheken für Service Bus.

Beispiel

Im folgenden Codebeispiel wird die Verwendung des Azure.Messaging.ServiceBus-Pakets veranschaulicht:

Legen Sie die Wiederholungsrichtlinie für einen ServiceBusClient mithilfe neuer ServiceBusClientOptions fest.
Erstellen Sie eine neue Nachricht mit einer neuen Instanz von ServiceBusMessage.
Senden Sie mithilfe der ServiceBusSender.SendMessageAsync(message)-Methode eine Nachricht an Service Bus.
Empfangen Sie mit dem ServiceBusReceiver, der als ServiceBusReceivedMessage-Objekte dargestellt wird.

using Azure.Identity;
using Azure.Messaging.ServiceBus;

string namespace = "<namespace>";
string queueName = "queue1";

// Because ServiceBusClient implements IAsyncDisposable, we'll create it 
// with "await using" so that it is automatically disposed for us.
var options = new ServiceBusClientOptions();
options.RetryOptions = new ServiceBusRetryOptions
{
    Delay = TimeSpan.FromSeconds(10),
    MaxDelay = TimeSpan.FromSeconds(30),
    Mode = ServiceBusRetryMode.Exponential,
    MaxRetries = 3,
};
await using var client = new ServiceBusClient(namespace, new DefaultAzureCredential(), options);

// The sender is responsible for publishing messages to the queue.
ServiceBusSender sender = client.CreateSender(queueName);
ServiceBusMessage message = new ServiceBusMessage("Hello world!");

await sender.SendMessageAsync(message);

// The receiver is responsible for reading messages from the queue.
ServiceBusReceiver receiver = client.CreateReceiver(queueName);
ServiceBusReceivedMessage receivedMessage = await receiver.ReceiveMessageAsync();

string body = receivedMessage.Body.ToString();
Console.WriteLine(body);

Nächste Schritte

Asynchrone Nachrichtenmuster und Hochverfügbarkeit

Service Fabric

Die Verteilung von Reliable Services in einem Service Fabric-Cluster dient als Schutz vor den meisten potenziellen vorübergehenden Fehlern, die in diesem Artikel beschrieben wurden. Einige vorübergehende Fehler sind aber weiterhin möglich. Für den Naming Service kann beispielsweise gerade eine Routingänderung durchgeführt werden, wenn er eine Anforderung erhält, sodass eine Ausnahme ausgelöst wird. Wenn dieselbe Anforderung 100 Millisekunden später eintrifft, ist der Vorgang wahrscheinlich erfolgreich.

Intern verwaltet Service Fabric diese Art von vorübergehenden Fehlern. Sie können einige Einstellungen konfigurieren, indem Sie beim Einrichten Ihrer Dienste die OperationRetrySettings-Klasse verwenden. Der folgende Code enthält hierzu ein Beispiel. In den meisten Fällen sollte dies nicht erforderlich sein, sodass die Standardeinstellungen verwendet werden können.

FabricTransportRemotingSettings transportSettings = new FabricTransportRemotingSettings
{
    OperationTimeout = TimeSpan.FromSeconds(30)
};

var retrySettings = new OperationRetrySettings(TimeSpan.FromSeconds(15), TimeSpan.FromSeconds(1), 5);

var clientFactory = new FabricTransportServiceRemotingClientFactory(transportSettings);

var serviceProxyFactory = new ServiceProxyFactory((c) => clientFactory, retrySettings);

var client = serviceProxyFactory.CreateServiceProxy<ISomeService>(
    new Uri("fabric:/SomeApp/SomeStatefulReliableService"),
    new ServicePartitionKey(0));

Nächste Schritte

Behandlung von Remotingausnahmen

SQL-Datenbank mit ADO.NET

SQL-Datenbank ist eine gehostete SQL-Datenbank, die in unterschiedlichen Größen und als Standard (freigegeben) und Premium (nicht freigegebenen)-Dienst verfügbar ist.

Wiederholungsmechanismus

SQL-Datenbank hat keine integrierte Unterstützung für Wiederholungen, wenn auf diese mit ADO.NET zugegriffen wird. Allerdings können die Rückgabecodes von Anforderungen verwendet werden, um zu bestimmen, warum eine Anforderung fehlgeschlagen ist. Weitere Informationen zur SQL-Datenbank-Drosselung finden Sie unter Ressourceneinschränkungen für Azure SQL-Datenbank. Eine Liste mit relevanten Fehlercodes finden Sie unter SQL-Fehlercodes für SQL-Datenbank-Clientanwendungen.

Sie können die Polly-Bibliothek verwenden, um Wiederholungen für SQL-Datenbank zu implementieren. Weitere Informationen finden Sie unter Behandeln von vorübergehenden Fehlern mit Polly.

Gebrauchsanleitung Wiederholungen

Beachten Sie den Zugriff auf SQL-Datenbank mit ADO.NET die folgenden Richtlinien:

Wählen Sie die entsprechende Dienstoption (freigegeben oder Premium). Bei einer freigegebenen Instanz kann es möglicherweise zu längeren Verbindungsverzögerungen als üblich und Drosselung durch die Verwendung des gemeinsam genutzten Servers durch andere Mandanten kommen. Wenn Vorgänge mit vorhersagbarerer Leistung und zuverlässig geringe Latenz erforderlich sind, sollten Sie die Premium-Option wählen.
Stellen Sie sicher, dass Sie Wiederholungen auf der entsprechenden Ebene oder im entsprechenden Bereich durchführen, um nicht-idempotente Operationen zu vermeiden, die Dateninkonsistenzen verursachen. Im Idealfall sollten alle Vorgänge idempotent sein, sodass sie ohne Inkonsistenzen wiederholt werden können. Wenn dies nicht der Fall ist, sollte die Wiederholung auf einer Ebene oder in einem Bereich durchgeführt werden, die ermöglichen, dass alle zugehörigen Änderungen rückgängig gemacht werden können, wenn bei einem Vorgang ein Fehler auftritt, zum Beispiel im Transaktionsbereich. Weitere Informationen finden Sie unter Clouddienst-Grundlagen Datenzugriffsebene - Handhabung vorübergehender Fehler.
Eine Strategie mit festgelegtem Intervall wird für die Verwendung mit Azure SQL-Datenbank nicht empfohlen, mit Ausnahme von interaktiven Szenarien, wo nur wenige Wiederholungen in kurzen Intervallen vorkommen. Ziehen Sie stattdessen eine exponentielle Backoff-Strategie für die meisten Szenarien in Betracht.
Wählen Sie einen geeigneten Wert für die Verbindungs- und Befehls-Timeouts bei der Definition von Verbindungen. Ein zu kurzes Timeout kann zu vorzeitigen Fehlern bei Verbindungen führen, wenn die Datenbank ausgelastet ist. Ein zu langes Timeout kann verhindern, dass die Wiederholungslogik ordnungsgemäß funktioniert, da sie vor der Erkennung einer fehlgeschlagenen Verbindung zu lange wartet. Der Wert für das Timeout ist eine Komponente der End-to-End-Latenz. Sie wird effektiv der Wiederholungsverzögerung hinzugefügt, die in der Wiederholungsrichtlinie für jeden Wiederholungsversuch festgelegt ist.
Schließen Sie die Verbindung nach einigen Wiederholungen, selbst wenn Sie eine exponentielle Backoff-Wiederholungslogik verwenden, und wiederholen Sie den Vorgang auf einer neuen Verbindung. Das mehrmalige Wiederholen des gleichen Vorgangs für dieselbe Verbindung kann ein Faktor sein, der zu Verbindungsproblemen beiträgt. Beispiele für dieses Verfahrens finden Sie unter Clouddienst-Grundlagen Datenzugriffsebene - Handhabung vorübergehender Fehler.
Wenn Verbindungspooling verwendet wird (Standardeinstellung), besteht die Möglichkeit, dass auch nach dem Schließen und erneuten Öffnen einer Verbindung dieselbe Verbindung aus dem Pool ausgewählt wird. Wenn dies der Fall ist, kommt zur Problembehandlung das Aufrufen der ClearPool-Methode der SqlConnection-Klasse infrage, um die Verbindung als nicht wiederverwendbar zu markieren. Allerdings sollten Sie dies erst nach mehreren fehlgeschlagenen Verbindungsversuchen tun und nur, wenn die spezifische Klasse des vorübergehende Fehler wie z. B. SQL-Timeouts (Fehlercode: -2) im Zusammenhang mit fehlerhaften Verbindungen auftritt.
Wenn der Datenzugriffscode als TransactionScope -Instanzen initiierte Transaktionen verwendet, sollte die Wiederholungslogik erneut eine Verbindung herstellen und einen neuen Transaktionsbereich initiieren. Aus diesem Grund sollte der wiederholbare Codeblock den gesamten Bereich der Transaktion umfassen.

Erwägen Sie, mit den folgenden Einstellungen für Wiederholungsvorgänge zu beginnen. Hierbei handelt es sich um allgemeine Einstellungen und Sie sollten die Vorgänge überwachen und die Werte entsprechend Ihrem Szenario optimieren.

Context	Beispielziel E2E maximale Wartezeit	Wiederholungsstrategie	Einstellungen	Werte	So funktioniert's
Interaktiv, Benutzeroberfläche oder Vordergrund	2 Sek	FixedInterval	Anzahl der Wiederholungen Wiederholungsintervall Erster schneller Wiederholungsversuch	3 500 ms true	Versuch 1 – Verzögerung 0 Sek. Versuch 2 – Verzögerung 500 ms Versuch 3 – Verzögerung 500 ms
Hintergrund oder Batch	30 Sek	ExponentialBackoff	Anzahl der Wiederholungen Min. Backoff Max. Backoff Delta-Backoff Erster schneller Wiederholungsversuch	5 0 Sek. 60 Sekunden 2 Sek false	Versuch 1 – Verzögerung 0 Sek. Versuch 2 – Verzögerung ca. 2 Sek. Versuch 3 – Verzögerung ca. 6 Sek. Versuch 4 – Verzögerung ca. 14 Sek. Versuch 5 – Verzögerung ca. 30 Sek.

Hinweis

Die End-to-End-Latenzziele setzen das Standardtimeout für Verbindungen mit dem Dienst voraus. Wenn Sie längere Verbindungstimeouts angeben, wird die End-to-End-Latenz durch diese zusätzliche Zeit für jeden Wiederholungsversuch erweitert.

Beispiele

In diesem Abschnitt wird veranschaulicht, wie Sie Polly zum Zugreifen auf Azure SQL-Datenbank verwenden können, indem Sie eine Reihe von Wiederholungsrichtlinien verwenden, die in der Policy-Klasse konfiguriert sind.

Der folgende Code enthält eine Erweiterungsmethode für die SqlCommand-Klasse, mit der ExecuteAsync mit exponentiell ansteigender Wartezeit aufgerufen wird.

public async static Task<SqlDataReader> ExecuteReaderWithRetryAsync(this SqlCommand command)
{
    GuardConnectionIsNotNull(command);

    var policy = Policy.Handle<Exception>().WaitAndRetryAsync(
        retryCount: 3, // Retry 3 times
        sleepDurationProvider: attempt => TimeSpan.FromMilliseconds(200 * Math.Pow(2, attempt - 1)), // Exponential backoff based on an initial 200 ms delay.
        onRetry: (exception, attempt) =>
        {
            // Capture some information for logging/telemetry.
            logger.LogWarn($"ExecuteReaderWithRetryAsync: Retry {attempt} due to {exception}.");
        });

    // Retry the following call according to the policy.
    await policy.ExecuteAsync<SqlDataReader>(async token =>
    {
        // This code is executed within the Policy

        if (conn.State != System.Data.ConnectionState.Open) await conn.OpenAsync(token);
        return await command.ExecuteReaderAsync(System.Data.CommandBehavior.Default, token);

    }, cancellationToken);
}

Diese asynchrone Erweiterungsmethode kann wie unten beschrieben verwendet werden.

var sqlCommand = sqlConnection.CreateCommand();
sqlCommand.CommandText = "[some query]";

using (var reader = await sqlCommand.ExecuteReaderWithRetryAsync())
{
    // Do something with the values
}

Nächste Schritte

Clouddienst-Grundlagen Datenzugriffsebene - Handhabung vorübergehender Fehler.

SQL-Datenbank mit Entity Framework 6

SQL-Datenbank ist eine gehostete SQL-Datenbank, die in unterschiedlichen Größen und als Standard (freigegeben) und Premium (nicht freigegebenen)-Dienst verfügbar ist. Entity Framework ist eine objektrelationale Zuordnung, die .NET Entwicklern die Arbeit mit relationalen Daten mithilfe von domänenspezifischen Objekten ermöglicht. Es entfällt die Notwendigkeit für den Großteil des Datenzugriffs-Codes, den Entwickler normalerweise schreiben müssen.

Wiederholungsmechanismus

Wenn auf SQL-Datenbank über Entity Framework 6.0 (oder eine höhere Version) zugegriffen wird, werden Wiederholungen über einen Mechanismus namens Verbindungsstabilität/Wiederholungslogik unterstützt. Die wichtigsten Features des Wiederholungsmechanismus sind:

Die primäre Abstraktion ist die IDbExecutionStrategy -Schnittstelle. Diese Benutzeroberfläche:
- Definiert die synchrone und die asynchrone Execute-Methode.
- Definiert Klassen, die direkt verwendet oder in einem Datenbankkontext als eine Standardstrategie konfiguriert werden können, einem Anbieternamen oder einem Anbieternamen und Servernamen zugeordnet werden können. Wenn sie für einen Kontext konfiguriert ist, treten Wiederholungen auf der Ebene der einzelnen Datenbankvorgängen auf, von denen es möglicherweise mehrere für einen angegebenen Kontext gibt.
- Definiert, wann und wie versucht wird, einen fehlgeschlagene Verbindung erneut herzustellen.
Sie umfasst mehrere integrierte Implementierungen für die IDbExecutionStrategy -Schnittstelle:
- Standard: keine Wiederholung.
- Standard für SQL-Datenbank (automatisch): kein erneuter Versuch, es werden jedoch Ausnahmen überprüft und in der SQL-Datenbank-Strategie mit der Empfehlung zur Verwendung eingebunden.
- Standardeinstellung für SQL-Datenbank: exponentiell (von der Basisklasse geerbt) plus SQL-Datenbank Erkennungslogik.
Sie implementiert eine exponentielle Backoff-Strategie, die einen Zufallsgenerator enthält.
Die integrierten Wiederholungsklassen sind zustandsbehaftet und nicht threadsicher. Sie können jedoch wiederverwendet werden, nachdem der aktuelle Vorgang abgeschlossen ist.
Wenn die angegebene Wiederholungsanzahl überschritten wird, werden die Ergebnisse in einer neue Ausnahme umschlossen. Sie bringt die aktuelle Ausnahme nicht zum Vorschein.

Richtlinienkonfiguration

Beim Zugriff auf SQL-Datenbank mit Entity Framework 6.0 und höher wird Wiederholungsunterstützung geboten. Wiederholungsrichtlinien werden programmgesteuert konfiguriert. Die Konfiguration kann nicht pro Vorgang geändert werden.

Wenn Sie eine Strategie im Kontext als Standard konfigurieren, geben Sie eine Funktion an, die bei Bedarf eine neue Strategie erstellt. Der folgende Code zeigt, wie Sie eine Wiederholungskonfigurationsklasse erstellen können, die die DbConfiguration -Basisklasse erweitert.

public class BloggingContextConfiguration : DbConfiguration
{
  public BlogConfiguration()
  {
    // Set up the execution strategy for SQL Database (exponential) with 5 retries and 4 sec delay
    this.SetExecutionStrategy(
         "System.Data.SqlClient", () => new SqlAzureExecutionStrategy(5, TimeSpan.FromSeconds(4)));
  }
}

Sie können diese dann mit der SetConfiguration-Methode der DbConfiguration-Instanz als Standardwiederholungsstrategie für alle Vorgänge festlegen, wenn die Anwendung gestartet wird. In der Standardeinstellung erkennt EF die Konfigurationsklasse automatisch und verwenden diese.

DbConfiguration.SetConfiguration(new BloggingContextConfiguration());

Sie können die Wiederholungskonfigurationsklasse für einen Kontext angeben, indem Sie die Kontextklasse mit einem DbConfigurationType -Attribut kommentieren. Wenn Sie jedoch über nur eine Konfigurationsklasse verfügen, wird EF diese verwenden, ohne dass der Kontext kommentieren werden muss.

[DbConfigurationType(typeof(BloggingContextConfiguration))]
public class BloggingContext : DbContext

Wenn Sie unterschiedliche Wiederholungsstrategien für bestimmte Vorgänge verwenden oder Wiederholungen für bestimmte Vorgänge deaktivieren müssen, können Sie eine Konfigurationsklasse erstellen, mit der Sie Strategien anhalten oder austauschen können, indem ein Flag in CallContextsetzen. Die Konfigurationsklasse kann dieses Flag verwenden, um Strategien zu wechseln oder die Strategie zu deaktivieren, die Sie bereitstellen und eine Standardstrategie verwenden. Weitere Informationen finden Sie unter Anhalten der Ausführungsstrategie (EF6 und höher).

Eine andere Technik für die Verwendung von bestimmten Wiederholungsstrategien für einzelne Vorgänge ist das Erstellen einer Instanz der erforderlichen Strategieklasse und das Liefern der gewünschten Einstellungen mithilfe von Parametern. Rufen Sie dann die ExecuteAsync -Methode auf.

var executionStrategy = new SqlAzureExecutionStrategy(5, TimeSpan.FromSeconds(4));
var blogs = await executionStrategy.ExecuteAsync(
    async () =>
    {
        using (var db = new BloggingContext("Blogs"))
        {
            // Acquire some values asynchronously and return them
        }
    },
    new CancellationToken()
);

Die einfachste Möglichkeit zum Verwenden einer DbConfiguration-Klasse ist es, diese in der gleichen Assembly wie die DbContext-Klasse zu platzieren. Dies ist jedoch nicht geeignet, wenn der gleiche Kontext in verschiedenen Szenarien benötigt wird, wie z. B. bei anderen interaktiven Strategien und Hintergrundwiederholungsstrategien. Wenn die unterschiedlichen Kontexte in separaten AppDomains ausgeführt werden, können Sie die integrierte Unterstützung für das Angeben von Konfigurationsklassen in der Konfigurationsdatei verwenden oder explizit mithilfe von Code festlegen. Wenn die unterschiedlichen Kontexte in derselben AppDomain ausgeführt werden müssen, ist eine benutzerdefinierte Lösung erforderlich.

Weitere Informationen finden Sie unter Codebasierte Konfiguration (EF6 und höher).

Die folgende Tabelle zeigt die Standardeinstellungen für die integrierte Wiederholungsrichtlinie bei Verwendung von EF6.

Einstellung	Standardwert	Bedeutung
Richtlinie	Exponentiell	Exponentielles Backoff.
MaxRetryCount	5	Die maximale Anzahl von Warnungen.
MaxDelay	30 Sekunden	Die maximale Verzögerung zwischen Wiederholungsversuchen. Dieser Wert hat keine Auswirkung auf die Berechnung der Verzögerungsreihen. Er definiert lediglich eine Obergrenze.
DefaultCoefficient	1 Sekunde	Der Koeffizient für die Berechnung des exponentiellen Backoffs. Dieser Wert kann nicht geändert werden.
DefaultRandomFactor	1.1	Der Multiplikator zum Hinzufügen einer beliebigen Verzögerung für die einzelnen Einträge. Dieser Wert kann nicht geändert werden.
DefaultExponentialBase	2	Der Multiplikator für die Berechnung der nächsten Verzögerung. Dieser Wert kann nicht geändert werden.

Gebrauchsanleitung Wiederholungen

Beachten Sie den Zugriff auf SQL-Datenbank mit EF6 die folgenden Richtlinien:

Wählen Sie die entsprechende Dienstoption (freigegeben oder Premium). Bei einer freigegebenen Instanz kann es möglicherweise zu längeren Verbindungsverzögerungen als üblich und Drosselung durch die Verwendung des gemeinsam genutzten Servers durch andere Mandanten kommen. Wenn Vorgänge mit vorhersagbarer Leistung und zuverlässig geringe Latenz erforderlich sind, sollten Sie die Premium-Option wählen.
Eine Strategie mit festgelegtem Intervall wird für die Verwendung mit Azure SQL-Datenbank nicht empfohlen. Verwenden Sie stattdessen eine exponentielle Backoff-Strategie, da der Dienst möglicherweise überlastet ist und längere Verzögerungen mehr Zeit für die Wiederherstellung einräumen.
Wählen Sie einen geeigneten Wert für die Verbindungs- und Befehls-Timeouts bei der Definition von Verbindungen. Stützen Sie das Timeout auf Ihren Geschäftslogikentwurf und auf Tests. Sie müssen diesen Wert möglicherweise mit der Zeit ändern, wenn sich die Datenmengen oder Geschäftsprozesse ändern. Ein zu kurzes Timeout kann zu vorzeitigen Fehlern bei Verbindungen führen, wenn die Datenbank ausgelastet ist. Ein zu langes Timeout kann verhindern, dass die Wiederholungslogik ordnungsgemäß funktioniert, da sie vor der Erkennung einer fehlgeschlagenen Verbindung zu lange wartet. Der Wert für das Timeout ist eine Komponente der End-to-End-Latenz, obwohl nicht leicht zu ermitteln ist, wie viele Befehle beim Speichern des Kontexts ausgeführt werden. Sie können das Standardtimeout ändern, indem Sie die Einstellung der CommandTimeout-Eigenschaft der DbContext-Instanz festlegen.
Entity Framework unterstützt Wiederholungskonfigurationen, die in Konfigurationsdateien definiert sind. Für maximale Flexibilität in Azure sollten Sie allerdings die Konfiguration in der Anwendung programmgesteuert erstellen. Die einzelnen Parameter für die Wiederholungsrichtlinien, wie z. B. die Anzahl der Wiederholungen und die Wiederholungsintervalle können in der Dienstkonfigurationsdatei gespeichert und zur Laufzeit verwendet werden, um die entsprechenden Richtlinien zu erstellen. Dadurch können die Einstellungen darin geändert werden, ohne dass die Anwendung neu gestartet werden muss.

Erwägen Sie, mit den folgenden Einstellungen für Wiederholungsvorgänge zu beginnen. Sie können die Verzögerung zwischen den Wiederholungen nicht angeben (sie ist als eine exponentielle Sequenz festgelegt und generiert). Sofern Sie keine benutzerdefinierte Wiederholungsstrategie erstellen, können Sie wie hier gezeigt nur die maximalen Werte angeben. Hierbei handelt es sich um allgemeine Einstellungen und Sie sollten die Vorgänge überwachen und die Werte entsprechend Ihrem Szenario optimieren.

Context	Beispielziel E2E maximale Wartezeit	Wiederholungsrichtlinie	Einstellungen	Werte	So funktioniert's
Interaktiv, Benutzeroberfläche oder Vordergrund	2 Sekunden	Exponentiell	MaxRetryCount MaxDelay	3 750 ms	Versuch 1 – Verzögerung 0 Sek. Versuch 2 – Verzögerung 750 ms Versuch 3 - Verzögerung 750 ms
Hintergrund oder Batch	30 Sekunden	Exponentiell	MaxRetryCount MaxDelay	5 12 Sekunden	Versuch 1 – Verzögerung 0 Sek. Versuch 2 – Verzögerung ca. 1 Sek. Versuch 3 – Verzögerung ca. 3 Sek. Versuch 4 – Verzögerung ca. 7 Sek. Versuch 5 – Verzögerung ca. 12 Sek.

Hinweis

Beispiele

Im folgenden Codebeispiel wird eine einfachen Datenzugriffslösung definiert, die Entity Framework verwendet. Eine bestimmte Wiederholungsstrategie wird durch die Definition einer Instanz einer Klasse mit dem Namen BlogConfiguration festgelegt, die DbConfiguration erweitert.

using System;
using System.Collections.Generic;
using System.Data.Entity;
using System.Data.Entity.SqlServer;
using System.Threading.Tasks;

namespace RetryCodeSamples
{
    public class BlogConfiguration : DbConfiguration
    {
        public BlogConfiguration()
        {
            // Set up the execution strategy for SQL Database (exponential) with 5 retries and 12 sec delay.
            // These values could be loaded from configuration rather than being hard-coded.
            this.SetExecutionStrategy(
                    "System.Data.SqlClient", () => new SqlAzureExecutionStrategy(5, TimeSpan.FromSeconds(12)));
        }
    }

    // Specify the configuration type if more than one has been defined.
    // [DbConfigurationType(typeof(BlogConfiguration))]
    public class BloggingContext : DbContext
    {
        // Definition of content goes here.
    }

    class EF6CodeSamples
    {
        public async static Task Samples()
        {
            // Execution strategy configured by DbConfiguration subclass, discovered automatically or
            // or explicitly indicated through configuration or with an attribute. Default is no retries.
            using (var db = new BloggingContext("Blogs"))
            {
                // Add, edit, delete blog items here, then:
                await db.SaveChangesAsync();
            }
        }
    }
}

Weitere Beispiele zur Verwendung des Entity Framework-Wiederholungsmechanismus finden Sie unter Verbindungsstabilität/Wiederholungslogik.

SQL-Datenbank mit Entity Framework Core

Entity Framework Core ist eine objektrelationale Zuordnung, die .NET Core-Entwicklern die Arbeit mit Daten mithilfe von domänenspezifischen Objekten ermöglicht. Es entfällt die Notwendigkeit für den Großteil des Datenzugriffs-Codes, den Entwickler normalerweise schreiben müssen. Diese Version von Entity Framework wurde von Grund auf neu geschrieben und erbt nicht automatisch alle Features von EF6.x.

Wiederholungsmechanismus

Wenn auf SQL-Datenbank über Entity Framework Core zugegriffen wird, werden Wiederholungen über einen Mechanismus namens Verbindungsstabilität unterstützt. Verbindungsstabilität wurde mit EF Core 1.1.0 eingeführt.

Die primäre Abstraktion ist die IExecutionStrategy-Schnittstelle. Die Ausführungsstrategie für SQL Server, einschließlich Azure SQL, ist über die Ausnahmetypen informiert, die wiederholt werden können, und verfügt über sinnvolle Standardwerte für maximale Wiederholungsversuche, Verzögerung zwischen Wiederholungen usw.

Beispiele

Der folgende Code ermöglicht automatische Wiederholungen beim Konfigurieren des DbContext-Objekts, das eine Sitzung mit der Datenbank repräsentiert.

protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
{
    optionsBuilder
        .UseSqlServer(
            @"Server=(localdb)\mssqllocaldb;Database=EFMiscellaneous.ConnectionResiliency;Trusted_Connection=True;",
            options => options.EnableRetryOnFailure());
}

Der folgende Code veranschaulicht, wie Sie eine Transaktion mit automatischen Wiederholungsversuchen ausführen, indem Sie eine Ausführungsstrategie verwenden. Die Transaktion wird in einem Delegaten definiert. Wenn ein vorübergehender Fehler auftritt, wird der Delegat von der Ausführungsstrategie erneut aufgerufen.

using (var db = new BloggingContext())
{
    var strategy = db.Database.CreateExecutionStrategy();

    strategy.Execute(() =>
    {
        using (var transaction = db.Database.BeginTransaction())
        {
            db.Blogs.Add(new Blog { Url = "https://blogs.msdn.com/dotnet" });
            db.SaveChanges();

            db.Blogs.Add(new Blog { Url = "https://blogs.msdn.com/visualstudio" });
            db.SaveChanges();

            transaction.Commit();
        }
    });
}

Azure Storage

Azure Storage-Dienste umfassen Blobspeicher sowie Dateien und Speicherwarteschlangen.

Blobs, Warteschlangen und Dateien

Die ClientOptions-Klasse ist der Basistyp für alle Typen von Clientoptionen, der verschiedene allgemeine Clientoptionen wie Diagnose, Wiederholung und Transport verfügbar macht. Zum Bereitstellen der Clientkonfigurationsoptionen für das Herstellen einer Verbindung mit Azure Queue, Blob und File Storage müssen Sie den entsprechenden abgeleiteten Typ verwenden. Im nächsten Beispiel verwenden Sie die QueueClientOptions-Klasse (abgeleitet von ClientOptions), um einen Client für die Verbindung mit Azure Queue Storage-Dienst zu konfigurieren. Die Retry-Eigenschaft umfasst Optionen, mit denen Sie beeinflussen können, wie Wiederholungsversuche ausgeführt werden und wann bei einem Fehler ein neuer Versuch erfolgt.

using System;
using System.Threading;
using Azure.Core;
using Azure.Identity;
using Azure.Storage;
using Azure.Storage.Queues;
using Azure.Storage.Queues.Models;

namespace RetryCodeSamples
{
    class AzureStorageCodeSamples {

        public async static Task Samples() {

               // Provide the client configuration options for connecting to Azure Queue Storage
                QueueClientOptions queueClientOptions = new QueueClientOptions()
                {
                    Retry = {
                    Delay = TimeSpan.FromSeconds(2),     //The delay between retry attempts for a fixed approach or the delay on which to base
                                                         //calculations for a backoff-based approach
                    MaxRetries = 5,                      //The maximum number of retry attempts before giving up
                    Mode = RetryMode.Exponential,        //The approach to use for calculating retry delays
                    MaxDelay = TimeSpan.FromSeconds(10)  //The maximum permissible delay between retry attempts
                    },

                    GeoRedundantSecondaryUri = new Uri("https://...")
                    // If the GeoRedundantSecondaryUri property is set, the secondary Uri will be used for GET or HEAD requests during retries.
                    // If the status of the response from the secondary Uri is a 404, then subsequent retries for the request will not use the
                    // secondary Uri again, as this indicates that the resource may not have propagated there yet.
                    // Otherwise, subsequent retries will alternate back and forth between primary and secondary Uri.
                };

                Uri queueServiceUri = new Uri("https://storageaccount.queue.core.windows.net/");
                string accountName = "Storage account name";
                string accountKey = "storage account key";

                // Create a client object for the Queue service, including QueueClientOptions.
                QueueServiceClient serviceClient = new QueueServiceClient(queueServiceUri, new DefaultAzureCredential(), queueClientOptions);

                CancellationTokenSource source = new CancellationTokenSource();
                CancellationToken cancellationToken = source.Token;

                // Return an async collection of queues in the storage account.
                var queues = serviceClient.GetQueuesAsync(QueueTraits.None, null, cancellationToken);

Tabellenunterstützung

Hinweis

Die Pakete WindowsAzure.Storage Nuget und Microsoft.Azure.Cosmos.Table Nuget sind veraltet. Informationen zur Azure-Tabellenunterstützung finden Sie unter Azure.Data.Tables Nuget-Paket.

Wiederholungsmechanismus

Die Clientbibliothek basiert auf der Azure Core-Bibliothek, einer Bibliothek, die übergreifende Dienste für andere Clientbibliotheken bereitstellt.

Ein Fehler kann aus verschiedenen Gründen auftreten, wenn eine Clientanwendung versucht, eine Netzwerkanforderung an einen Dienst zu senden. Einige Beispiele sind Zeitüberschreitungen, Ausfälle der Netzwerkinfrastruktur, Ablehnung der Anforderung durch den Dienst aufgrund von Drosselung/Belastung, Beendigung der Dienstinstanz aufgrund von Skalierung des Dienstes, Herunterfahren der Dienstinstanz, damit diese durch eine andere Version ersetzt werden kann, Absturz des Dienstes aufgrund einer unbehandelten Ausnahme, usw. Durch die Bereitstellung eines integrierten Wiederholungsmechanismus (mit einer Standardkonfiguration, die der Verbraucher überschreiben kann) werden unsere SDKs und die Anwendung des Consumers widerstandsfähig gegen diese Arten von Fehlern. Beachten Sie, dass einige Dienste pro Anforderung echtes Geld verlangen. Daher sollten die Consumer die Möglichkeit haben, die Wiederholungsversuche vollständig zu deaktivieren, wenn ihnen Kosteneinsparungen wichtiger sind als Ausfallsicherheit.

Richtlinienkonfiguration

Wiederholungsrichtlinien werden programmgesteuert konfiguriert. Die Konfiguration basiert auf der RetryOption-Klasse. Es gibt ein Attribut für TableClientOptions, das von ClientOptions geerbt wird.

var tableClientOptions = new TableClientOptions();
tableClientOptions.Retry.Mode = RetryMode.Exponential;
tableClientOptions.Retry.MaxRetries = 5;
var serviceClient = new TableServiceClient("<endpoint>", new DefaultAzureCredential(), tableClientOptions);

Die folgenden Tabellen enthalten die Möglichkeiten für die integrierten Wiederholungsrichtlinien.

RetryOption

Einstellung	Bedeutung
Verzögern	Die Verzögerung zwischen Wiederholungsversuchen für einen festen Ansatz oder die Verzögerung, auf der Berechnungen für einen backoffbasierten Ansatz basieren. Wenn der Dienst einen Retry-After-Antwortheader bereitstellt, wird die nächste Wiederholung um die vom Headerwert angegebene Dauer verzögert.
MaxDelay	Die maximal zulässige Verzögerung zwischen Wiederholungsversuchen, wenn der Dienst keinen Retry-After-Antwortheader bereitstellt. Wenn der Dienst einen Retry-After-Antwortheader bereitstellt, wird die nächste Wiederholung um die vom Headerwert angegebene Dauer verzögert.
Mode	Die Methode, die zum Berechnen von Wiederholungsverzögerungen verwendet werden soll
NetworkTimeout	Die Zeitüberschreitung, die für einen einzelnen Netzwerkvorgang gilt.

RetryMode

Einstellung	Bedeutung
Exponentiell	Wiederholungsversuche werden auf Basis einer Backoffstrategie verzögert, wobei jeder Versuch die Wartezeit vor einem neuen Versuch erhöht.
MaxDelay	Wiederholungsversuche erfolgen in festen Intervallen. Die Dauer der Verzögerungen ist konsistent.

Telemetrie

Die einfachste Möglichkeit, die Protokolle anzuzeigen, besteht darin, die Konsolenprotokollierung zu aktivieren. Verwenden Sie die AzureEventSourceListener.CreateConsoleLogger-Methode, um einen Azure SDK-Protokolllistener zu erstellen, der Nachrichten an die Konsole ausgibt.

// Setup a listener to monitor logged events.
using AzureEventSourceListener listener = AzureEventSourceListener.CreateConsoleLogger();

Beispiele

Die Ausführung des folgenden Codebeispiels mit heruntergefahrenem Speicheremulator ermöglicht es uns, Informationen zu Wiederholungen in der Konsole anzuzeigen.

using Azure.Core;
using Azure.Core.Diagnostics;
using Azure.Data.Tables;
using Azure.Data.Tables.Models;
using Azure.Identity;

namespace RetryCodeSamples
{
    class AzureStorageCodeSamples
    {
        private const string tableName = "RetryTestTable";

        public async static Task SamplesAsync()
        {
            // Setup a listener to monitor logged events.
            using AzureEventSourceListener listener = AzureEventSourceListener.CreateConsoleLogger();

            var tableClientOptions = new TableClientOptions();
            tableClientOptions.Retry.Mode = RetryMode.Exponential;
            tableClientOptions.Retry.MaxRetries = 5;

            var serviceClient = new TableServiceClient("<endpoint>", new DefaultAzureCredential(), tableClientOptions);

            TableItem table = await serviceClient.CreateTableIfNotExistsAsync(tableName);
            Console.WriteLine($"The created table's name is {table.Name}.");
        }
    }
}

Allgemeine REST-und Wiederholungsrichtlinien

Berücksichtigen Sie beim Zugriff auf die Dienste von Azure oder von Drittanbietern Folgendes:

Verwenden Sie einen systematischen Ansatz zur Verwaltung von Wiederholungen, vielleicht als wiederverwendbaren Code, sodass Sie eine einheitliche Methodik für alle Clients und alle Lösungen anwenden können.
Verwenden Sie ggf. ein Wiederholungsframework wie Polly, um Wiederholungen zu verwalten, wenn der Zieldienst oder der Client nicht über einen integrierten Wiederholungsmechanismus verfügt. Dies hilft Ihnen bei der Implementierung eines konsistenten Wiederholungsverhaltens, und kann eine geeignete Standardwiederholungsstrategie für den Zieldienst bereitstellen. Sie müssen aber unter Umständen einen benutzerdefinierten Wiederholungscode für Dienste erstellen, die kein Standardverhalten aufweisen und nicht auf Ausnahmen vertrauen, um vorübergehende Fehler anzuzeigen, oder wenn Sie eine Retry-Response-Antwort verwenden möchten, um das Wiederholungsverhalten zu verwalten.
Die vorübergehende Erkennungslogik hängt von der tatsächlichen Client-API ab, die Sie verwenden, um die REST-Aufrufe aufzurufen. Einige Clients, z. B. die neuere HttpClient-Klasse, lösen keine Ausnahmen für abgeschlossene Anforderungen mit einem nicht erfolgreichen HTTP-Statuscode aus.
Der vom Dienst zurückgegebene HTTP-Statuscode kann dabei helfen, zu erkennen, ob der Fehler vorübergehend ist. Möglicherweise müssen Sie die Ausnahmen, die von einem Client oder dem Wiederholungsframework erzeugt wurden untersuchen, um auf den Statuscode zuzugreifen oder um den entsprechenden Ausnahmetyp bestimmen zu können. Die folgenden HTTP-Codes geben in der Regel an, dass eine Wiederholung geeignet ist:
- 408 Anforderungstimeout
- 429 – Zu viele Anforderungen
- 500 Interner Serverfehler
- 502 Ungültiges Gateway
- 503 Dienst nicht verfügbar
- 504 Gateway-Timeout
Wenn Sie Ihre Wiederholungslogik auf Ausnahmen basieren, wird in der Regel durch Folgendes angezeigt, dass ein vorübergehender Fehler besteht, da keine Verbindung hergestellt werden konnte:
- WebExceptionStatus.ConnectionClosed
- WebExceptionStatus.ConnectFailure
- WebExceptionStatus.Timeout
- WebExceptionStatus.RequestCanceled
Im Fall des Status „Dienst nicht verfügbar“ weist der Dienst unter Umständen auf die entsprechende Verzögerung vor der Wiederholung im Retry-After -Antwort-Header oder in einem anderen benutzerdefinierten Header hin. Dienste können auch zusätzliche Informationen als benutzerdefinierte Header oder in den Inhalt der Antwort eingebettet senden.
Führen Sie keine Wiederholung für Statuscodes durch, die Clientfehler (Fehler im Bereich 4xx) darstellen, mit Ausnahme des Fehlers 408 (Anforderungstimeout) und 429 (Zu viele Anforderungen).
Testen Sie Ihre Wiederholungsstrategien und Mechanismen gründlich unter verschiedenen Bedingungen, wie z. B. verschiedenen Netzwerkzuständen und sich ändernden Systemlastverteilungen.

Wiederholungsstrategien

Im Folgenden sind die typischen Arten von Wiederholungsstrategie-Intervallen dargestellt:

Exponential: Eine Wiederholungsrichtlinie, mit der eine angegebene Anzahl von Wiederholungsversuchen durchgeführt wird, bei der ein zufälliger exponentieller Backoff-Ansatz zur Ermittlung des Intervalls zwischen den Wiederholungsversuchen verwendet wird. Beispiel:

var random = new Random();

var delta = (int)((Math.Pow(2.0, currentRetryCount) - 1.0) *
            random.Next((int)(this.deltaBackoff.TotalMilliseconds * 0.8),
            (int)(this.deltaBackoff.TotalMilliseconds * 1.2)));
var interval = (int)Math.Min(checked(this.minBackoff.TotalMilliseconds + delta),
                this.maxBackoff.TotalMilliseconds);
retryInterval = TimeSpan.FromMilliseconds(interval);

Incremental: Eine Wiederholungsstrategie mit einer angegebenen Anzahl von Wiederholungsversuchen und einem inkrementellen Zeitintervall zwischen den Wiederholungen. Beispiel:
```
retryInterval = TimeSpan.FromMilliseconds(this.initialInterval.TotalMilliseconds +
                (this.increment.TotalMilliseconds * currentRetryCount));
```
LinearRetry: Eine Wiederholungsrichtlinie, bei der eine angegebene Anzahl von Wiederholungen durchgeführt und ein angegebenes festes Zeitintervall zwischen den Wiederholungen verwendet wird. Beispiel:
```
retryInterval = this.deltaBackoff;
```

Behandeln von vorübergehenden Fehlern mit Polly

Polly ist eine Bibliothek zur programmgesteuerten Behandlung von Wiederholungsversuchen und Schutzschalter-Strategien. Das Polly-Projekt ist ein Mitglied der .NET Foundation. Für Dienste, bei denen der Client Wiederholungsversuche nicht nativ unterstützt, ist Polly eine zulässige Alternative. Es ist hierbei nicht erforderlich, benutzerdefinierten Code für die Wiederholungsversuche zu schreiben, dessen richtige Implementierung schwierig sein kann. Polly bietet auch eine Möglichkeit zum Überwachen des Auftretens von Fehlern, damit Sie Wiederholungsversuche protokollieren können.

Nächste Schritte

Entity Framework Verbindungsresilienz

Freigeben über

Wiederholungsanleitung für Azure-Dienste

Microsoft Entra ID

Wiederholungsmechanismus

Gebrauchsanleitung Wiederholungen

Nächste Schritte

Azure Cosmos DB

Wiederholungsmechanismus

Telemetrie

Data Lake Store

Wiederholungsmechanismus

Telemetrie

Event Hubs

Wiederholungsmechanismus

Beispiel

Nächste Schritte

IoT Hub

Wiederholungsmechanismus

Richtlinienkonfiguration

Nächste Schritte

Azure Cache for Redis

Wiederholungsmechanismus

Richtlinienkonfiguration

Gebrauchsanleitung Wiederholungen

Telemetrie

Beispiele

Nächste Schritte

Azure Search

Wiederholungsmechanismus

Telemetrie

Service Bus

Wiederholungsmechanismus

Gebrauchsanleitung Wiederholungen

Telemetrie

Beispiel

Nächste Schritte

Service Fabric

Nächste Schritte

SQL-Datenbank mit ADO.NET

Wiederholungsmechanismus

Gebrauchsanleitung Wiederholungen

Beispiele

Nächste Schritte

SQL-Datenbank mit Entity Framework 6

Wiederholungsmechanismus

Richtlinienkonfiguration

Gebrauchsanleitung Wiederholungen

Beispiele

SQL-Datenbank mit Entity Framework Core

Wiederholungsmechanismus

Beispiele

Azure Storage

Blobs, Warteschlangen und Dateien

Tabellenunterstützung

Wiederholungsmechanismus

Richtlinienkonfiguration

RetryMode

Telemetrie

Beispiele

Allgemeine REST-und Wiederholungsrichtlinien

Wiederholungsstrategien

Behandeln von vorübergehenden Fehlern mit Polly

Nächste Schritte

Feedback

Zusätzliche Ressourcen