Implementieren einer Wiederholungsrichtlinie mit .NET

Jede Anwendung, die in der Cloud ausgeführt wird oder mit Remotediensten und Ressourcen kommuniziert, muss vorübergehende Fehler verarbeiten können. Es ist üblich, dass bei diesen Anwendungen Fehler auftreten. Gründe dafür könnten ein vorübergehender Verlust der Netzwerkkonnektivität, ein Anforderungstimeout, das eintritt, wenn ein Dienst oder eine Ressource stark beansprucht wird, oder andere Faktoren sein. Entwickler sollten Anwendungen erstellen, die vorübergehende Fehler transparent verarbeiten, um die Stabilität und Resilienz zu verbessern.

In diesem Artikel erfahren Sie, wie Sie mithilfe der Azure Storage-Clientbibliothek für .NET eine Wiederholungsrichtlinie für eine Anwendung einrichten, die eine Verbindung mit Azure Blob Storage herstellt. Wiederholungsrichtlinien definieren, wie die Anwendung fehlgeschlagene Anforderungen verarbeitet, und sollten immer angepasst werden, damit sie den geschäftlichen Anforderungen der Anwendung und der Art des Fehlers entsprechen.

Konfigurieren von Wiederholungsoptionen

Wiederholungsrichtlinien für Blob Storage werden programmgesteuert konfiguriert und bieten Kontrolle darüber, wie Wiederholungsoptionen auf verschiedene Dienstanforderungen und Szenarien angewendet werden. Beispielsweise kann eine Web-App, die Anforderungen basierend auf der Benutzerinteraktion ausgibt, eine Richtlinie mit weniger Wiederholungen und kürzeren Verzögerungen implementieren. Dadurch wird die Reaktionsfähigkeit erhöht und der Benutzer benachrichtigt, wenn ein Fehler auftritt. Alternativ kann eine App oder Komponente, die Batchanforderungen im Hintergrund ausführt, die Anzahl der Wiederholungen erhöhen und eine exponentielle Backoff-Strategie verwenden. Somit wird ein erfolgreicher Abschluss der Anforderungszeit ermöglicht.

In der folgenden Tabelle sind die Eigenschaften der RetryOptions-Klasse zusammen mit dem Typ, einer Kurzbeschreibung und dem Standardwert aufgeführt, wenn Sie keine Änderungen vornehmen. Sie sollten die Werte dieser Eigenschaften proaktiv optimieren, um die Anforderungen Ihrer App zu erfüllen.

In diesem Beispiel für Blob Storage konfigurieren Sie die Wiederholungsoptionen in der Retry-Eigenschaft der BlobClientOptions-Klasse. Anschließend erstellen wir ein Clientobjekt für den Blobdienst mithilfe der Wiederholungsoptionen.

// Provide the client configuration options for connecting to Azure Blob Storage
BlobClientOptions blobOptions = new BlobClientOptions()
{
    Retry = {
        Delay = TimeSpan.FromSeconds(2),
        MaxRetries = 5,
        Mode = RetryMode.Exponential,
        MaxDelay = TimeSpan.FromSeconds(10),
        NetworkTimeout = TimeSpan.FromSeconds(100)
    },
};

BlobServiceClient blobServiceClient = new BlobServiceClient(
    accountUri,
    new DefaultAzureCredential(),
    blobOptions);

In diesem Beispiel verwendet jede Dienstanforderung, die vom BlobServiceClient-Objekt ausgestellt wurde, die Wiederholungsoptionen wie im BlobClientOptions-Objekt definiert. Basierend auf den Anforderungen Ihrer App können Sie verschiedene Wiederholungsstrategien für Dienstclients konfigurieren.

Verwenden von Georedundanz zur Verbesserung der App-Resilienz

Wenn für Ihre App eine hohe Verfügbarkeit und eine höhere Resilienz gegenüber Fehlern erforderlich sind, können Sie Georedundanzoptionen von Azure Storage als Teil Ihrer Wiederholungsrichtlinie nutzen. Speicherkonten, die für die georedundante Replikation konfiguriert sind, werden synchron in der primären Region und asynchron in einer sekundären Region repliziert, die mehrere hundert Kilometer entfernt ist.

Azure Storage bietet zwei Optionen für die georedundante Replikation: georedundanter Speicher (GRS) und geozonenredundanter Speicher (GZRS). Zusätzlich zur Aktivierung der Georedundanz für Ihr Speicherkonto müssen Sie auch den Lesezugriff auf die Daten in der sekundären Region konfigurieren. Informationen zum Ändern von Replikationsoptionen für Ihr Speicherkonto finden Sie unter Ändern der Replikation eines Speicherkontos.

In diesem Beispiel legen Sie die Eigenschaft GeoRedundantSecondaryUri in BlobClientOptions fest. Wenn diese Eigenschaft festgelegt ist, wird der sekundäre URI für GET- oder HEAD-Anforderungen während Wiederholungen verwendet. Wenn der Status der Antwort vom sekundären URI 404 lautet, verwenden nachfolgende Wiederholungen für die Anforderung nicht erneut den sekundären URI, da dieser Statuscode angibt, dass die Ressource dort möglicherweise noch nicht weitergegeben wurde. Andernfalls wechseln sich nachfolgende Wiederholungen zwischen primärem und sekundärem URI ab.

Uri secondaryAccountUri = new Uri($"https://{accountName}-secondary.blob.core.windows.net/");

// Provide the client configuration options for connecting to Azure Blob Storage
BlobClientOptions blobOptionsGRS = new BlobClientOptions()
{
    Retry = {
        Delay = TimeSpan.FromSeconds(2),
        MaxRetries = 5,
        Mode = RetryMode.Exponential,
        MaxDelay = TimeSpan.FromSeconds(10),
        NetworkTimeout = TimeSpan.FromSeconds(100)
    },

    // Set the secondary storage URI
    GeoRedundantSecondaryUri = secondaryAccountUri
};

BlobServiceClient blobServiceClient = new BlobServiceClient(
    accountUri,
    new DefaultAzureCredential(),
    blobOptionsGRS);

Apps, die Georedundanz verwenden, müssen einige spezifische Entwurfsaspekte berücksichtigen. Weitere Informationen erhalten Sie unter Verwenden von Georedundanz zum Entwerfen hochverfügbarer Anwendungen.

Nächste Schritte

• Dieser Artikel ist Teil des Blob Storage-Entwicklerleitfadens für .NET. Die vollständige Liste der Artikel im Entwicklerleitfaden finden Sie unter Erstellen Ihrer App.
• Ein Leitfaden zur Architektur und allgemeine bewährte Methoden für Wiederholungsrichtlinien finden Sie unter Behandeln vorübergehender Fehler.
• Leitfäden zum Implementieren eines Wiederholungsmusters für vorübergehende Fehler finden Sie unter Wiederholungsmuster.