Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
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 des Azure Storage-Clientmoduls für Go eine Wiederholungsrichtlinie für eine Anwendung konfigurieren, 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 Felder, die zum Konfigurieren einer RetryOptions-Instanz verfügbar sind, zusammen mit dem Typ, einer kurzen Beschreibung 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.
| Eigenschaft | Typ | BESCHREIBUNG | Standardwert |
|---|---|---|---|
MaxRetries |
int32 |
Optional. Gibt an, wie oft ein fehlerhafter Vorgang maximal wiederholt wird, bevor ein Fehler generiert wird. Ein Wert unter Null steht für einen Versuch und keine Wiederholungen. | 3 |
TryTimeout |
time.Duration |
Optional. Gibt die maximal zulässige Zeit für jeden einzelnen Versuch einer HTTP-Anforderung an. Geben Sie einen Wert größer 0 an, um die Option zu aktivieren. Hinweis: Das Festlegen dieses Felds auf einen kleinen Wert kann zu vorzeitigen HTTP-Anforderungstimeouts führen. | Standardmäßig deaktiviert. |
RetryDelay |
time.Duration |
Optional. Gibt die anfängliche Verzögerung an, die vor dem Wiederholen eines Vorgangs verwendet werden soll. Der Wert wird nur verwendet, wenn die HTTP-Antwort keinen Retry-After-Header enthält. Die Verzögerung erhöht sich exponentiell mit jeder Wiederholung bis zum maximalen Wert, der „MaxRetryDelay“ angegeben wird. Ein Wert kleiner als 0 bedeutet keine Verzögerung zwischen Wiederholungen. | 4 Sekunden |
MaxRetryDelay |
time.Duration |
Optional. Gibt die maximale Verzögerung an, die vor dem Wiederholen eines Vorgangs zulässig ist. Der Wert ist in der Regel größer als der in RetryDelay angegebene Wert oder gleich diesem Wert. Ein Wert kleiner als Null bedeutet, dass kein Maximum vorhanden ist. |
60 Sekunden |
StatusCodes |
[]int | Optional. Gibt die HTTP-Statuscodes an, die angeben, dass der Vorgang wiederholt werden soll. Durch Angeben von Werten werden die Standardwerte ersetzt. Wenn Sie einen leeren Slice angeben, werden Wiederholungsversuche für HTTP-Statuscodes deaktiviert. | 408 - http.StatusRequestTimeout 429 - http.StatusTooManyRequests 500 - http.StatusInternalServerError 502 - http.StatusBadGateway 503 - http.StatusServiceUnavailable 504 - http.StatusGatewayTimeout |
ShouldRetry |
func(*http.Response, error) bool |
Optional. Wertet aus, ob die Wiederholungsrichtlinie die Anforderung wiederholen soll. Wenn diese Eigenschaft angegeben wird, überschreibt die Funktion den Vergleich mit der Liste der HTTP-Statuscodes und der Fehlerüberprüfung innerhalb der Wiederholungsrichtlinie. Fehler vom Typ Context und NonRetriable bleiben vor dem Aufrufen von ShouldRetry ausgewertet. Die Parameter *http.Response und error schließen sich gegenseitig aus, d. h., wenn ein Parameter nil ist, ist der andere nicht nil. Ein Rückgabewert von „true“ bedeutet, dass die Wiederholungsrichtlinie den Vorgang wiederholen soll. |
Um mit dem Codebeispiel in diesem Abschnitt zu arbeiten, fügen Sie Ihrem Code die folgenden import-Pfade hinzu:
import (
"context"
"time"
"github.com/Azure/azure-sdk-for-go/sdk/azcore"
"github.com/Azure/azure-sdk-for-go/sdk/azcore/policy"
"github.com/Azure/azure-sdk-for-go/sdk/azidentity"
"github.com/Azure/azure-sdk-for-go/sdk/storage/azblob"
)
Im folgenden Codebeispiel konfigurieren wir die Wiederholungsoptionen in einer Instanz von RetryOptions, nehmen Sie in eine ClientOptions-Instanz auf, und erstellen ein neues Clientobjekt:
options := azblob.ClientOptions{
ClientOptions: azcore.ClientOptions{
Retry: policy.RetryOptions{
MaxRetries: 10,
TryTimeout: time.Minute * 15,
RetryDelay: time.Second * 1,
MaxRetryDelay: time.Second * 60,
StatusCodes: []int{408, 429, 500, 502, 503, 504},
},
},
}
credential, err := azidentity.NewDefaultAzureCredential(nil)
handleError(err)
client, err := azblob.NewClient(accountURL, credential, &options)
handleError(err)
In diesem Beispiel verwendet jede von client ausgegebene Dienstanforderung die Wiederholungsoptionen wie in der RetryOptions-Struktur definiert. Diese Richtlinie gilt für Clientanforderungen. Basierend auf den Anforderungen Ihrer App können Sie verschiedene Wiederholungsstrategien für Dienstclients konfigurieren.
Zugehöriger Inhalt
- 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.