Wskazówki dotyczące ponawiania prób dla usług platformy Azure

Większość usług platformy Azure i zestawów SDK klienta zawiera mechanizm ponawiania prób. Różnią się one jednak między sobą, ponieważ każda usługa ma inne cechy i wymagania, więc każdy mechanizm ponawiania jest dostosowany do konkretnej usługi. Ten przewodnik zawiera podsumowanie funkcji mechanizmu ponawiania dla większości usług platformy Azure oraz informacje ułatwiające korzystanie, dostosowywanie lub rozszerzanie mechanizmu ponawiania prób dla tej usługi.

Aby uzyskać ogólne wskazówki na temat obsługi błędów przejściowych, a także próby ponownego nawiązywania połączeń oraz wykonywania operacji dotyczących usług i zasobów, zobacz Wskazówki dotyczące ponawiania prób.

Poniższa tabela zawiera podsumowanie funkcji ponawiania prób dla usług platformy Azure opisanych w tym artykule.

Usługa	Możliwości ponawiania prób	Konfiguracja zasad	Scope	Funkcje telemetrii
Tożsamość Microsoft Entra	Natywna w bibliotece biblioteki MSAL	Osadzone w bibliotece biblioteki MSAL	Wewnętrzny	Brak
Azure Cosmos DB	Natywne w usłudze	Niekonfigurowalna	Globalnie	TraceSource
Data Lake Store	Natywne w kliencie	Niekonfigurowalna	Poszczególne operacje	Brak
Event Hubs	Natywne w kliencie	Programowa	Klient	Brak
IoT Hub	Natywny w zestawie SDK klienta	Programowa	Klient	Brak
Azure Cache for Redis	Natywne w kliencie	Programowa	Klient	TextWriter
Wyszukaj	Natywne w kliencie	Programowa	Klient	Śledzenie zdarzeń dla systemu Windows (ETW) lub niestandardowe
Service Bus	Natywne w kliencie	Programowa	Menedżer przestrzeni nazw, fabryka obsługi komunikatów i klient	ETW
Service Fabric	Natywne w kliencie	Programowa	Klient	Brak
Usługa SQL Database i platforma ADO.NET	Usługa Polly	Deklaracyjne i programowe	Pojedyncze instrukcje lub bloki kodu	Niestandardowy
Usługa SQL Database i platforma Entity Framework	Natywne w kliencie	Programowa	Globalny dla domeny aplikacji	Brak
Usługa SQL Database i platforma Entity Framework Core	Natywne w kliencie	Programowa	Globalny dla domeny aplikacji	Brak
Storage	Natywne w kliencie	Programowa	Klient i indywidualne operacje	TraceSource

Uwaga

W przypadku większości wbudowanych mechanizmów ponawiania prób platformy Azure obecnie nie ma możliwości zastosowania różnych zasad ponawiania dla różnych typów błędów lub wyjątków. Należy skonfigurować zasady zapewniające optymalną średnią wydajność i dostępność. Jednym ze sposobów dostosowania zasad jest przeprowadzenie analizy plików dziennika w celu określenia rodzaju występujących błędów przejściowych.

Microsoft Entra ID

Microsoft Entra ID to kompleksowe rozwiązanie do zarządzania tożsamościami i dostępem w chmurze, które łączy podstawowe usługi katalogowe, zaawansowane zarządzanie tożsamościami, zabezpieczenia i zarządzanie dostępem do aplikacji. Firma Microsoft Entra ID oferuje również deweloperom platformę zarządzania tożsamościami w celu zapewnienia kontroli dostępu do swoich aplikacji w oparciu o scentralizowane zasady i reguły.

Uwaga

Aby uzyskać wskazówki dotyczące ponawiania prób dotyczących punktów końcowych tożsamości usługi zarządzanej, zobacz Jak używać tożsamości usługi zarządzanej (MSI) maszyny wirtualnej platformy Azure do uzyskiwania tokenu.

Mechanizm ponawiania prób

Istnieje wbudowany mechanizm ponawiania prób dla identyfikatora entra firmy Microsoft w bibliotece Microsoft Authentication Library (MSAL). Aby uniknąć nieoczekiwanych blokad, zalecamy, aby biblioteki innych firm i kod aplikacji nie ponawiały próby nieudanych połączeń, ale umożliwiają bibliotece MSAL obsługę ponownych prób.

Wskazówki dotyczące używania mechanizmu ponawiania prób

Podczas korzystania z identyfikatora Entra firmy Microsoft należy wziąć pod uwagę następujące wskazówki:

• Jeśli to możliwe, użyj biblioteki MSAL i wbudowanej obsługi ponownych prób.
• Jeśli używasz interfejsu API REST dla identyfikatora Entra firmy Microsoft, spróbuj ponownie wykonać operację, jeśli kod wyniku to 429 (zbyt wiele żądań) lub błąd w zakresie 5xx. Nie należy ponawiać próby w przypadku innych błędów.
• W przypadku błędów 429 spróbuj ponownie tylko po upływie czasu wskazanego w nagłówku Ponów próbę po .
• W przypadku błędów 5xx należy użyć wycofywania wykładniczego, a pierwsze ponowienie próby co najmniej 5 sekund po odpowiedzi.
• Nie ponawiaj próby w przypadku błędów innych niż 429 i 5xx.

Następne kroki

• Biblioteka Microsoft Authentication Library (MSAL)

Azure Cosmos DB

Azure Cosmos DB to w pełni zarządzana wielomodelowa baza danych, która obsługuje dane JSON bez schematu. Została opracowana z myślą o chmurze z elastycznym skalowaniem i oferuje niezawodne działanie z możliwością konfiguracji oraz natywne przetwarzanie transakcyjne języka JavaScript.

Mechanizm ponawiania prób

Zestawy SDK usługi Azure Cosmos DB automatycznie ponawiają próby w określonych warunkach błędów, a aplikacje użytkowników są zachęcane do posiadania własnych zasad ponawiania prób. Zapoznaj się z przewodnikiem projektowania odpornych aplikacji przy użyciu zestawów SDK usługi Azure Cosmos DB, aby uzyskać pełną listę warunków błędów i czas ponawiania próby.

Telemetria

W zależności od języka aplikacji dane diagnostyczne i telemetryczne są widoczne jako dzienniki lub promowane właściwości odpowiedzi operacji. Aby uzyskać więcej informacji, zobacz sekcję "Przechwytywanie diagnostyki" w zestawie SDK języka C# usługi Azure Cosmos DB i zestawie SDK języka Java usługi Azure Cosmos DB.

Data Lake Store

Usługa Data Lake Storage Gen2 sprawia, że usługa Azure Storage stanowi podstawę do tworzenia magazynów danych przedsiębiorstwa na platformie Azure. Usługa Data Lake Storage Gen2 umożliwia łatwe zarządzanie ogromnymi ilościami danych.

Biblioteka kliencka usługi Azure Storage Files Data Lake zawiera wszystkie funkcje wymagane do ułatwienia deweloperom, analitykom danych i analitykom przechowywania danych o dowolnym rozmiarze, kształcie i szybkości oraz we wszystkich typach przetwarzania i analizy na różnych platformach i językach.

Mechanizm ponawiania prób

Obiekt DataLakeServiceClient umożliwia manipulowanie zasobami usługi Azure Data Lake i systemami plików. Konto magazynu zapewnia przestrzeń nazw najwyższego poziomu dla usługi Data Lake. Podczas tworzenia klienta można podać opcje konfiguracji klienta służące do nawiązywania połączenia z usługą Azure Data Lake (DataLakeClientOptions). Obiekt DataLakeClientOptions zawiera właściwość Ponów próbę (dziedziczona z klasy Azure.Core.ClientOptions), którą można skonfigurować (klasa RetryOptions).

Telemetria

Monitorowanie użycia i wydajności usługi Azure Storage jest ważną częścią operacjonalizacji usługi. Przykłady obejmują częste operacje, operacje z dużym opóźnieniem lub operacjami, które powodują ograniczanie przepustowości po stronie usługi.

Wszystkie dane telemetryczne dla konta magazynu są dostępne za pośrednictwem dzienników usługi Azure Storage w usłudze Azure Monitor. Ta funkcja integruje konto magazynu z usługami Log Analytics i Event Hubs, a jednocześnie umożliwia archiwizowanie dzienników na innym koncie magazynu. Aby wyświetlić pełną listę metryk i dzienników zasobów oraz skojarzony ze nimi schemat, zobacz Dokumentacja danych monitorowania usługi Azure Storage.

Event Hubs

Azure Event Hubs to usługa pozyskiwania danych telemetrycznych w hiperskala, która zbiera, przekształca i przechowuje miliony zdarzeń.

Mechanizm ponawiania prób

Sposób ponawiania w bibliotece klienta usługi Azure Event Hubs jest kontrolowany przez właściwość RetryPolicy klasy EventHubClient. Domyślne zasady ponawiają próby z wycofywaniem wykładniczym, gdy usługa Azure Event Hubs zwraca przejściowy EventHubsException lub OperationCanceledException. Domyślne zasady ponawiania dla usługi Event Hubs to ponawianie próby do 9 razy z wykładniczym czasem wycofywania do 30 sekund.

Przykład

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

Następne kroki

Biblioteka klienta usługi Azure Event Hubs dla platformy .NET

Usługa IoT Hub

Azure IoT Hub to usługa służąca do łączenia, monitorowania i zarządzania urządzeniami w celu tworzenia aplikacji Internetu rzeczy (IoT).

Mechanizm ponawiania prób

Zestaw SDK urządzeń usługi Azure IoT może wykrywać błędy w sieci, protokole lub aplikacji. Na podstawie typu błędu zestaw SDK sprawdza, czy należy wykonać ponowną próbę. Jeśli błąd można odzyskać, zestaw SDK zacznie ponawiać próbę przy użyciu skonfigurowanych zasad ponawiania prób.

Domyślne zasady ponawiania prób to wycofywanie wykładnicze z losowym zakłóceniami, ale można je skonfigurować.

Konfiguracja zasad

Konfiguracja zasad różni się w zależności od języka. Aby uzyskać więcej informacji, zobacz Konfiguracja zasad ponawiania prób w usłudze IoT Hub.

Następne kroki

• Zasady ponawiania prób w usłudze IoT Hub
• Rozwiązywanie problemów z rozłączaniem urządzeń w usłudze IoT Hub

Azure Cache for Redis

Azure Cache for Redis to szybka usługa pamięci podręcznej z dostępem do danych i małymi opóźnieniami oparta na popularnej pamięci podręcznej Redis Typu open source. Jest ona bezpieczna, zarządzana przez firmę Microsoft i jest dostępna z dowolnej aplikacji na platformie Azure.

Wskazówki zawarte w tej sekcji dotyczą korzystania z klienta StackExchange.Redis w celu uzyskiwania dostępu do pamięci podręcznej. Listę innych odpowiednich klientów można znaleźć w witrynie internetowej usługi Redis. Każdy z nich może mieć inny mechanizm ponawiania.

Klient StackExchange.Redis używa multipleksowania za pośrednictwem jednego połączenia. Zaleca się utworzenie wystąpienia klienta przy uruchamianiu aplikacji i użycie tego wystąpienia w przypadku wszystkich operacji dotyczących pamięci podręcznej. Z tego powodu próba nawiązania połączenia z pamięcią podręczną jest wykonywana tylko raz, więc wszystkie wskazówki zawarte w tej sekcji dotyczą zasady ponawiania dla tego początkowego połączenia, a nie dla każdej operacji, która pozwala uzyskać dostęp do pamięci podręcznej.

Mechanizm ponawiania prób

Klient StackExchange.Redis używa klasy menedżera połączeń skonfigurowanej za pomocą zestawu opcji, w tym:

• ConnectRetry. Liczba ponownych prób nawiązania połączenia z pamięcią podręczną.
• ReconnectRetryPolicy. Strategia ponawiania, która ma zostać użyta.
• ConnectTimeout. Maksymalny czas oczekiwania w milisekundach.

Konfiguracja zasad

Zasady ponawiania są konfigurowane programowo przez ustawienie opcji dla klienta przed nawiązaniem podłączenia z pamięcią podręczną. Można to zrobić przez utworzenie wystąpienia klasy ConfigurationOptions, wypełnienie jej właściwości i przekazanie jej do metody Connect.

Wbudowane klasy zapewniają obsługę opóźnień liniowych (stałych) i wykładniczych wycofań z losowymi interwałami ponawiania prób. Można również utworzyć zasady niestandardowe ponawiania, implementując interfejs IReconnectRetryPolicy.

Poniższy przykład umożliwia skonfigurowanie strategii ponawiania przy użyciu wykładniczego wycofywania.

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);

Ewentualnie można też określić opcje jako ciąg i przekazać go do metody Connect. Nie można ustawić właściwości ReconnectRetryPolicy w ten sposób tylko za pomocą kodu.

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

Opcje można również określić bezpośrednio po nawiązaniu połączenia z pamięcią podręczną.

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

Aby uzyskać więcej informacji, zobacz Stack Exchange Redis Configuration (Konfigurowanie elementu Stack Exchange Redis) w dokumentacji StackExchange.Redis.

W poniższej tabeli przedstawiono ustawienia domyślne dla wbudowanej zasady ponawiania.

Kontekst	Ustawienie	Wartość domyślna (v 1.2.2)	Znaczenie
ConfigurationOptions	ConnectRetry ConnectTimeout SyncTimeout ReconnectRetryPolicy	3 Maksymalnie 5000 ms plus wartość przypisana do elementu SyncTimeout 1000 LinearRetry = 5000 ms	Liczba powtórzeń prób nawiązania połączenia podczas początkowej operacji nawiązywania połączenia. Limit czasu (ms) dla operacji dotyczących połączenia. Brak opóźnienia między ponownymi próbami. Czas (ms) przeznaczony na operacje synchroniczne. Próby podejmowane co 5000 ms.

Uwaga

W przypadku operacji synchronicznych element SyncTimeout może zwiększyć całkowite opóźnienie, ale ustawienie zbyt niskiej wartości może spowodować zbyt częste przekraczanie limitów czasu. Aby uzyskać więcej informacji, zobacz Jak rozwiązywać problemy z usługą Azure Cache for Redis. Zaleca się, aby unikać operacji synchronicznych na korzyść operacji asynchronicznych. Aby uzyskać więcej informacji, zobacz Pipelines and Multiplexers (Potoki i multipleksery).

Wskazówki dotyczące używania mechanizmu ponawiania prób

Podczas korzystania z usługi Azure Cache for Redis należy wziąć pod uwagę następujące wskazówki:

• Klient StackExchange Redis zarządza własnymi ponowieniami, ale tylko podczas nawiązywania połączenia z pamięcią podręczną przy pierwszym uruchomieniu aplikacji. Możesz skonfigurować limit czasu połączenia, liczbę ponownych prób oraz czas między ponownymi próbami nawiązania tego połączenia, ale zasady ponawiania nie dotyczą operacji względem pamięci podręcznej.
• Zamiast wykonywania dużej liczby ponowień, należy wziąć pod uwagę zmianę podejścia i uzyskać dostęp do oryginalnego źródła danych.

Telemetria

Informacje dotyczące połączenia, z wykluczeniem innych operacji, można uzyskać za pomocą elementu TextWriter.

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

Poniżej przedstawiono przykład danych wyjściowych wygenerowanych przez ten element.

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...
...

Przykłady

Poniższy przykład kodu umożliwia skonfigurowanie stałych (liniowych) opóźnień między kolejnymi próbami podczas inicjowania klienta StackExchange.Redis. W tym przykładzie pokazano, jak ustawić konfigurację za pomocą wystąpienia ConfigurationOptions.

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;
                }
            }
        }
    }
}

W następnym przykładzie konfiguracja została ustawiona przez przypisanie opcjom postaci ciągu. Limit czasu połączenia to maksymalny czas oczekiwania na połączenie z pamięcią podręczną, a nie opóźnienie między ponownymi próbami. Właściwość ReconnectRetryPolicy może być ustawiana tylko za pomocą kodu.

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;
                }
            }
        }
    }
}

Aby uzyskać więcej przykładów, zobacz Configuration (Konfigurowanie) w witrynie internetowej projektu.

Następne kroki

• Witryna internetowa usługi Redis

Azure Search

Usługa Azure Search umożliwia dodawanie zaawansowanych i złożonych możliwości wyszukiwania do witryny internetowej lub aplikacji, szybkie i łatwe dostosowywanie wyników wyszukiwania oraz tworzenie zaawansowanych i zoptymalizowanych modeli klasyfikacji.

Mechanizm ponawiania prób

Zestaw Azure SDK dla platformy .NET zawiera bibliotekę klienta Azure.Search.Documents z zespołu zestawu Azure SDK, która jest funkcjonalnie równoważna poprzedniej bibliotece klienta Microsoft.Azure.Search.

Zachowanie ponawiania prób w usłudze Microsoft.Azure.Search jest kontrolowane przez metodę SetRetryPolicy w klasach SearchServiceClient i SearchIndexClient. Domyślne zasady ponawiają próby z wykorzystaniem wykładniczego wycofywania, gdy usługa Azure Search zwraca odpowiedź 5xx lub 408 (limit czasu żądania).

Zachowanie ponawiania prób w pliku Azure.Search.Documents jest kontrolowane przez element SearchClientOptions (jest częścią konstruktora SearchClient) we właściwości Retry, która należy do klasy Azure.Core.RetryOptions (gdzie są dostępne wszystkie konfiguracje).

Telemetria

Śledzenie za pomocą funkcji ETW lub po zarejestrowaniu niestandardowego dostawcy śledzenia. Aby uzyskać więcej informacji, zapoznaj się z dokumentacją dotyczącą narzędzia AutoRest.

Service Bus

Service Bus to platforma do obsługi komunikatów w chmurze, która umożliwia swobodną wymianę komunikatów, co ułatwia skalowanie i zwiększa odporność składników aplikacji (lokalnie lub w chmurze).

Mechanizm ponawiania prób

Przestrzeń nazw i niektóre szczegóły konfiguracji zależą od tego, który pakiet zestawu SDK klienta usługi Service Bus jest używany:

Pakiet	opis	Przestrzeń nazw
Azure.Messaging.ServiceBus	Biblioteka klienta usługi Azure Service Bus dla platformy .NET	Azure.Messaging.ServiceBus
WindowsAzure.ServiceBus	Ten pakiet jest starszą biblioteką klienta usługi Service Bus. Wymaga programu .NET Framework 4.5.2.	Microsoft.Azure.ServiceBus

Wskazówki dotyczące używania mechanizmu ponawiania prób

Właściwość ServiceBusRetryOptions określa opcje ServiceBusClient ponawiania dla obiektu:

Ustawienie	Domyślna wartość	Znaczenie
CustomRetryPolicy		Niestandardowe zasady ponawiania prób, które mają być używane zamiast poszczególnych wartości opcji.
Opóźnienie	0,8 sekundy	Opóźnienie między próbami ponawiania próby dla stałego podejścia lub opóźnieniem, na którym mają być oparte obliczenia na podstawie podejścia opartego na wycofywaniu.
MaxDelay	60 s	Maksymalne dopuszczalne opóźnienie między próbami ponawiania prób.
Maksymalna liczba ponownych prób	3	Maksymalna liczba ponownych prób przed rozważeniem skojarzonej operacji zakończyła się niepowodzeniem.
Tryb	Wykładniczy	Podejście do obliczania opóźnień ponawiania prób.
TryTimeout	60 s	Maksymalny czas trwania oczekiwania na ukończenie pojedynczej próby, niezależnie od tego, czy próba początkowa, czy ponowna próba.

Mode Ustaw właściwość , aby skonfigurować właściwość ServiceBusRetryMode przy użyciu dowolnej z następujących wartości:

Właściwości	Wartość	Opis
Wykładniczy	1	Próby ponawiania będą opóźniać w oparciu o strategię wycofywania, w której każda próba zwiększy czas oczekiwania przed ponowną próbą.
Stała	0	Próby ponawiania są wykonywane w ustalonych odstępach czasu; każde opóźnienie jest stałym czasem trwania.

Przykład:

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);

Telemetria

Usługa Service Bus zbiera te same rodzaje danych monitorowania co inne zasoby platformy Azure. Usługę Azure Service Bus można monitorować przy użyciu usługi Azure Monitor.

Dostępne są również różne opcje wysyłania danych telemetrycznych za pomocą bibliotek klienckich .NET usługi Service Bus.

• Śledzenie za pomocą usługi aplikacja systemu Azure Insights
• Śledzenie za pomocą funkcji OpenTelemetry

Przykład

W poniższym przykładzie Azure.Messaging.ServiceBus kodu pokazano, jak używać pakietu do:

• Ustaw zasady ponawiania dla ServiceBusClient elementu przy użyciu nowego ServiceBusClientOptionselementu .
• Utwórz nowy komunikat z nowym wystąpieniem klasy ServiceBusMessage.
• Wyślij komunikat do usługi Service Bus przy użyciu ServiceBusSender.SendMessageAsync(message) metody .
• Odbieraj ServiceBusReceiverprzy użyciu obiektu , które są reprezentowane jako ServiceBusReceivedMessage obiekty.

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);

Następne kroki

• Wzorce asynchronicznej obsługi komunikatów i wysoka dostępność

Service Fabric

Dystrybucja niezawodnych usług w klastrze usługi Service Fabric chroni przed większością potencjalnych błędów przejściowych omówionych w tym artykule. Niektóre błędy przejściowe są jednak nadal możliwe. Usługa nazewnictwa może na przykład być w trakcie wykonywania operacji zmiany routingu, gdy otrzyma żądanie, które wymusi zgłoszenie wyjątku. Jeśli to samo żądanie przyjdzie 100 milisekund później, prawdopodobnie zakończy się powodzeniem.

Usługa Service Fabric zarządza wewnętrznie tego rodzaju błędami przejściowymi. Niektóre ustawienia można skonfigurować za pomocą klasy OperationRetrySettings podczas konfigurowania usług. Poniższy kod przedstawia przykład. W większości przypadków nie powinno to być konieczne, a ustawienia domyślne będą poprawne.

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));

Następne kroki

• Obsługa wyjątków komunikacji zdalnie

Usługa SQL Database korzystająca z ADO.NET

Usługa SQL Database to hostowana baza danych SQL Database dostępna w różnych rozmiarach oraz jako usługa standardowa (współdzielona) i Premium (nieudostępna).

Mechanizm ponawiania prób

Usługa SQL Database nie ma wbudowanej obsługi ponawiania, która mogłaby być wykorzystywana podczas uzyskiwania do niej dostępu za pomocą platformy ADO.NET. Kody powrotu z żądań mogą jednak posłużyć do ustalenia przyczyny niepowodzenia żądania. Aby uzyskać więcej informacji o ograniczaniu przepływności usługi SQL Database, zobacz Limity zasobów usługi Azure SQL Database. Aby uzyskać informacje o liście kodów błędów, zobacz Kody błędów SQL w aplikacjach klienckich usługi SQL Database.

Zaimplementowanie ponownych prób na potrzeby usługi SQL Database jest możliwe za pomocą biblioteki Polly. Aby uzyskać więcej informacji, zobacz Obsługa błędów przejściowych w usłudze Polly.

Wskazówki dotyczące używania mechanizmu ponawiania prób

Podczas uzyskiwania dostępu do usługi SQL Database przy użyciu platformy ADO.NET należy wziąć pod uwagę następujące zalecenia:

• Wybierz odpowiednią opcję dotyczącą usługi (udostępniana lub premium). Wystąpienie udostępnione może być dłużej niż zwykle narażone na opóźnienia w połączeniu oraz ograniczenia przepływności spowodowane używaniem przez innych dzierżawców udostępnionego serwera. Jeśli wymagana jest bardziej przewidywalna wydajność oraz małe opóźnienia niezawodnych operacji, warto wybrać opcję premium.
• Upewnij się, że ponawianie jest przeprowadzane na odpowiednim poziomie lub w odpowiednim zakresie, aby uniknąć powodowania przez operacje nieidempotentne niespójności w danych. Najlepiej jeśli wszystkie operacje są idempotentne, dzięki czemu mogą być powtórzone bez powodowania niespójności. Jeśli tak nie jest, należy ponowić próbę na poziomie lub zakresie, który umożliwia cofnięcie wszystkich powiązanych zmian w przypadku niepowodzenia jednej operacji; na przykład z zakresu transakcyjnego. Aby uzyskać więcej informacji, zobacz Cloud Service Fundamentals Data Access Layer – Transient Fault Handling (Warstwa dostępu do danych w aplikacji Cloud Service Fundamentals — obsługa błędów przejściowych).
• Strategia stałego interwału nie jest zalecana do użycia z usługą Azure SQL Database z wyjątkiem scenariuszy interaktywnych, w których istnieje tylko kilka ponownych prób w krótkich odstępach czasu. Zamiast tego rozważ użycie strategii wycofywania wykładniczego dla większości scenariuszy.
• Wybierz odpowiednią wartość dla limitu czasu połączenia i polecenia podczas definiowania połączeń. Zbyt krótki limit czasu może spowodować przedwczesne niepowodzenia połączeń, gdy baza danych jest zajęta. Zbyt długi limit czasu może uniemożliwiać prawidłowe funkcjonowanie logiki ponawiania z powodu zbyt długiego czasu oczekiwania na wykrycie połączenia zakończonego niepowodzeniem. Wartość limitu czasu jest składnikiem kompleksowego opóźnienia; Jest on skutecznie dodawany do opóźnienia ponawiania określonego w zasadach ponawiania dla każdej próby ponawiania.
• Zamknij połączenie po niektórych ponownych próbach, nawet jeśli używasz logiki ponawiania prób wykładniczo, i spróbuj ponownie wykonać operację na nowym połączeniu. Wielokrotne ponawianie tej samej operacji przy tym samym połączeniu może być czynnikiem, który przyczynia się do problemów z połączeniem. Aby poznać przykład korzystania z tej techniki, zobacz Cloud Service Fundamentals Data Access Layer – Transient Fault Handling (Warstwa dostępu do danych w aplikacji Cloud Service Fundamentals — obsługa błędów przejściowych).
• Jeśli buforowanie połączeń jest używane (ustawienie domyślne), istnieje prawdopodobieństwo, że to samo połączenie zostanie wybrane z puli, nawet po zamknięciu i ponownym otwarciu połączenia. Jeśli tak, technika rozpoznawania problemu polega na wywołaniu metody ClearPool klasy SqlConnection, aby oznaczyć połączenie jako niezdatne do wielokrotnego użytku. Ten krok należy jednak wykonać tylko wtedy, gdy kilka prób nawiązania połączenia zakończyło się niepowodzeniem i tylko w przypadku napotkania określonej klasy błędów przejściowych, takich jak przekroczenia limitu czasu dla bazy danych SQL (kod błędu: -2) powiązanych z błędnymi połączeniami.
• Jeśli kod dostępu do danych używa transakcji zainicjowanych jako wyjątki TransactionScope, logika ponawiania powinna ponownie otworzyć połączenie i zainicjować nowy zakres transakcji. Z tego powodu blok kodu powtarzający operację powinien obejmować cały zakres transakcji.

W przypadku operacji ponawiania rozważ rozpoczęcie od następujących ustawień. Te ustawienia są ogólnego przeznaczenia i należy monitorować operacje i dostosowywać wartości do własnych scenariuszy.

Kontekst	Przykładowy docelowy E2E maksymalne opóźnienie	Strategia ponawiania prób	Ustawienia	Wartości	Jak to działa
Interaktywny, interfejs użytkownika lub pierwszy plan	2 sek.	FixedInterval	Liczba ponownych prób Interwał ponawiania prób Pierwsze szybkie ponowienie	3 500 ms prawda	Próba 1 — opóźnienie 0 sek. Próba 2 — opóźnienie 500 ms Próba 3 — opóźnienie 500 ms
Tło lub partia	30 sek	ExponentialBackoff	Liczba ponownych prób Minimalna liczba wycofań Maksymalna liczba wycofań Różnica w liczbie wycofań Pierwsze szybkie ponowienie	5 0 sek. 60 sek. 2 sek. fałsz	Próba 1 — opóźnienie 0 sek. Próba 2 — opóźnienie ok. 2 sek. Próba 3 — opóźnienie ok. 6 sek. Próba 4 — opóźnienie ok. 14 sek. Próba 5 — opóźnienie ok. 30 sek.

Uwaga

Wartości docelowe opóźnienia całkowitego zakładają domyślny limit czasu połączenia z usługą. W przypadku określenia dłuższych limitów czasu połączenia opóźnienie całkowite zostanie przedłużone o ten dodatkowy czas dla każdego ponowienia próby.

Przykłady

W tej sekcji pokazano, w jaki sposób można użyć usługi Polly do uzyskania dostępu do usługi Azure SQL Database przy użyciu zestawu zasad ponawiania skonfigurowanych w klasie Policy.

Poniższy kod zawiera metodę rozszerzenia klasy SqlCommand, która wywołuje metodę ExecuteAsync za pomocą wykładniczego wycofywania.

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);
}

Ta metoda asynchronicznego rozszerzenia może być używana w następujący sposób.

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

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

Następne kroki

• Cloud Service Fundamentals Data Access Layer – Transient Fault Handling (Warstwa dostępu do danych w aplikacji Cloud Service Fundamentals — obsługa błędów przejściowych).

Usługa SQL Database korzystająca z programu Entity Framework 6

Usługa SQL Database to hostowana baza danych SQL Database dostępna w różnych rozmiarach oraz jako usługa standardowa (współdzielona) i Premium (nieudostępna). Entity Framework to maper obiektowo-relacyjny, który umożliwia deweloperom platformy .NET pracować z danymi relacyjnymi przy użyciu obiektów specyficznych dla domeny. Dzięki takiemu rozwiązaniu deweloperzy nie muszą pisać wielu linijek kodu dostępu do danych.

Mechanizm ponawiania prób

Obsługa ponawiania prób jest zapewniana podczas uzyskiwania dostępu do usługi SQL Database przy użyciu programu Entity Framework 6.0 lub nowszego za pomocą mechanizmu o nazwie Odporność połączenia/logika ponawiania prób. Główne funkcje mechanizmu ponawiania prób to:

• Podstawową abstrakcją jest interfejs IDbExecutionStrategy. Ten interfejs:
  • Definiuje metody wykonywania synchronicznego i asynchronicznego.
  • Definiuje klasy, które mogą być bezpośrednio używane lub konfigurowane w kontekście bazy danych w formie strategii domyślnej, zamapowanej na nazwę dostawcy lub zamapowanej na nazwę dostawcy i nazwę serwera. Po skonfigurowaniu w kontekście ponowienia występują na poziomie pojedynczych operacji bazy danych, z których każda może mieć kilka dla danej operacji w kontekście.
  • Określa, kiedy należy ponowić próbę nawiązania połączenia, które się nie powiodło, oraz w jaki sposób.
• Zawiera on kilka wbudowanych implementacji interfejsu IDbExecutionStrategy :
  • Ustawienie domyślne: brak ponawiania próby.
  • Wartość domyślna dla usługi SQL Database (automatyczna): nie jest ponawiana, ale sprawdza wyjątki i opakowuje je sugestią użycia strategii usługi SQL Database.
  • Wartość domyślna dla usługi SQL Database: wykładnicza (dziedziczona z klasy bazowej) i logiki wykrywania usługi SQL Database.
• Wprowadza strategię wycofywania wykładniczego, która uwzględnia generowanie losowe.
• Wbudowane klasy ponawiania prób są stanowe i nie są bezpieczne wątkowo. Mogą one jednak zostać ponownie użyte po zakończeniu bieżącej operacji.
• Po przekroczeniu określonej liczby ponownych prób wyniki zostaną opakowane w nowym wyjątku. Nie jest on bąbelkowy w górę bieżącego wyjątku.

Konfiguracja zasad

Wsparcie dotyczące ponawiania prób jest zapewniane podczas uzyskiwania dostępu do usługi SQL Database przy użyciu platformy Entity Framework 6.0 lub nowszej. Zasady ponawiania prób są konfigurowane programowo. Nie można zmienić konfiguracji dla poszczególnych operacji.

Podczas konfigurowania strategii w kontekście domyślnym należy określić funkcję, która tworzy nową strategię na żądanie. Poniższy kod przedstawia sposób tworzenia klasy konfiguracji ponawiania, która rozszerza klasę podstawową DbConfiguration.

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)));
  }
}

Następnie można określić tę klasę jako domyślną strategię ponawiania dla wszystkich operacji za pomocą metody SetConfiguration wystąpienia DbConfiguration podczas uruchamiania aplikacji. Domyślnie platforma EF automatycznie wykrywa klasę konfiguracji i używa jej.

DbConfiguration.SetConfiguration(new BloggingContextConfiguration());

Dla kontekstu można określić klasę konfiguracji ponawiania, dodając adnotację do klasy kontekstu z atrybutem DbConfigurationType. Jeśli jednak masz tylko jedną klasę konfiguracji, platforma EF użyje jej bez konieczności dodawania adnotacji do kontekstu.

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

Jeśli konieczne jest użycie różnych strategii ponawiania lub ich wyłączenie dla określonych operacji, można utworzyć klasy konfiguracji, które umożliwiają wstrzymanie lub wymianę strategii przez ustawienie flagi w elemencie CallContext. Klasa konfiguracji może używać tej flagi do przełączania strategii lub wyłączania wybranej strategii i używania domyślnej. Aby uzyskać więcej informacji, zobacz Temat Suspend Execution Strategy (EF6 onward).

Inna technika stosowania określonych strategii ponawiania dla poszczególnych operacji polega na utworzeniu wystąpienia wymaganej klasy strategii i dostarczeniu odpowiednich ustawień za pomocą parametrów. Następnie należy wywołać jej metodę ExecuteAsync.

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()
);

Najprostszym sposobem użycia klasy DbConfiguration jest umieszczenie jej w tym samym zestawie co klasa DbContext. Nie jest to jednak odpowiednie, gdy ten sam kontekst jest wymagany w różnych scenariuszach, takich jak różne interaktywne i strategie ponawiania prób w tle. Jeśli różne konteksty są wykonywane w oddzielnych domenach aplikacji, można użyć wbudowanej obsługi w celu określania klas konfiguracji w pliku konfiguracyjnym lub ustawić go jawnie przy użyciu kodu. Jeśli różne konteksty muszą być wykonywane w tej samej domenie aplikacji, potrzebne będzie niestandardowe rozwiązanie.

Aby uzyskać więcej informacji, zobacz Konfiguracja oparta na kodzie (EF6).

W poniższych tabelach przedstawiono ustawienia domyślne dla wbudowanej zasady ponawiania podczas korzystania z platformy EF6.

Ustawienie	Domyślna wartość	Znaczenie
Zasady	Wykładniczy	Wycofywanie wykładnicze.
MaxRetryCount	5	Maksymalna liczba ponownych prób.
MaxDelay	30 sekund	Maksymalne opóźnienie między kolejnymi próbami. Ta wartość nie ma wpływu na sposób obliczania serii opóźnień. Określa tylko górną granicę opóźnień.
DefaultCoefficient	1 sekunda	Współczynnik służący do obliczania wykładniczego wycofywania. Tej wartości nie można zmienić.
DefaultRandomFactor	1.1	Mnożnik używany do dodawania losowego opóźnienia dla każdego wpisu. Tej wartości nie można zmienić.
DefaultExponentialBase	2	Mnożnik używany do obliczania następnego opóźnienia. Tej wartości nie można zmienić.

Wskazówki dotyczące używania mechanizmu ponawiania prób

Podczas uzyskiwania dostępu do usługi SQL Database przy użyciu platformy EF6 należy wziąć pod uwagę następujące zalecenia:

• Wybierz odpowiednią opcję dotyczącą usługi (udostępniana lub premium). Wystąpienie udostępnione może być dłużej niż zwykle narażone na opóźnienia w połączeniu oraz ograniczenia przepływności spowodowane używaniem przez innych dzierżawców udostępnionego serwera. Jeśli wymagana jest przewidywalna wydajność oraz małe opóźnienia niezawodnych operacji, należy wziąć pod uwagę wybranie opcji premium.

• Strategia stałego interwału nie jest zalecana do użycia z usługą Azure SQL Database. Zamiast tego należy użyć strategii wykładniczego wycofywania, ponieważ usługa może być przeciążona, a dłuższe opóźnienia to więcej czasu na odzyskiwanie.

• Wybierz odpowiednią wartość dla limitu czasu połączenia i polecenia podczas definiowania połączeń. Ustawiając limit czasu, należy bazować na projekcie logiki biznesowej i dokładnych testach. Po pewnym czasie może być konieczne zmodyfikowanie tej wartości, ponieważ ilości danych i procesy biznesowe ulegają zmianom. Zbyt krótki limit czasu może spowodować przedwczesne niepowodzenia połączeń, gdy baza danych jest zajęta. Zbyt długi limit czasu może uniemożliwiać prawidłowe funkcjonowanie logiki ponawiania z powodu zbyt długiego czasu oczekiwania na wykrycie połączenia zakończonego niepowodzeniem. Wartość limitu czasu jest składnikiem kompleksowego opóźnienia, chociaż nie można łatwo określić, ile poleceń zostanie wykonanych podczas zapisywania kontekstu. Domyślny limit czasu można zmienić, określając właściwość CommandTimeout wystąpienia DbContext.

• Platforma Entity Framework obsługuje konfiguracje ponowień określone w plikach konfiguracji. Jednak aby uzyskać maksymalną elastyczność na platformie Azure, należy rozważyć utworzenie konfiguracji programowo w aplikacji. Określone parametry dla zasad ponawiania, takie jak liczba ponownych prób i interwałów ponawiania, mogą być przechowywane w pliku konfiguracji usługi i używane w czasie wykonywania w celu utworzenia odpowiednich zasad. Dzięki temu ustawienia można zmieniać bez konieczności ponownego uruchamiania aplikacji.

W przypadku operacji ponawiania rozważ rozpoczęcie od następujących ustawień. Nie można określić opóźnienia między próbami ponawiania (jest ono stałe i generowane jako sekwencja wykładnicza). Można określić tylko maksymalne wartości, jak pokazano poniżej, chyba że tworzona jest strategia niestandardowych ponowień. Te ustawienia są ogólnego przeznaczenia i należy monitorować operacje i dostosowywać wartości do własnych scenariuszy.

Kontekst	Przykładowy docelowy E2E maksymalne opóźnienie	Zasady ponawiania	Ustawienia	Wartości	Jak to działa
Interaktywny, interfejs użytkownika lub pierwszy plan	2 sekundy	Wykładniczy	MaxRetryCount MaxDelay	3 750 ms	Próba 1 — opóźnienie 0 sek. Próba 2 — opóźnienie 750 ms Próba 3 — opóźnienie 750 ms
Tło lub partia	30 sekund	Wykładniczy	MaxRetryCount MaxDelay	5 12 sekund	Próba 1 — opóźnienie 0 sek. Próba 2 — opóźnienie ok. 1 sek. Próba 3 — opóźnienie ok. 3 sek. Próba 4 — opóźnienie ok. 7 sek. Próba 5 — opóźnienie 12 sek.

Uwaga

Wartości docelowe opóźnienia całkowitego zakładają domyślny limit czasu połączenia z usługą. W przypadku określenia dłuższych limitów czasu połączenia opóźnienie całkowite zostanie przedłużone o ten dodatkowy czas dla każdego ponowienia próby.

Przykłady

Poniższy przykład kodu przedstawia proste rozwiązanie w zakresie dostępu do danych, które korzysta z platformy Entity Framework. Ustawia ono określoną strategię ponawiania, określając wystąpienie klasy o nazwie BlogConfiguration stanowiącej rozszerzenie klasy DbConfiguration.

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();
            }
        }
    }
}

Więcej przykładów użycia mechanizmu ponawiania prób programu Entity Framework można znaleźć w temacie Odporność połączenia /logika ponawiania prób.

Usługa SQL Database korzystająca z platformy Entity Framework Core

Entity Framework Core to maper obiektowo-relacyjny, który umożliwia deweloperom platformy .NET Core pracować z danymi przy użyciu obiektów specyficznych dla domeny. Dzięki takiemu rozwiązaniu deweloperzy nie muszą pisać wielu linijek kodu dostępu do danych. Ta wersja platformy Entity Framework została napisana od podstaw i nie dziedziczy automatycznie wszystkich funkcji wersji EF6.x.

Mechanizm ponawiania prób

Obsługa ponawiania prób jest zapewniana podczas uzyskiwania dostępu do usługi SQL Database przy użyciu programu Entity Framework Core za pomocą mechanizmu nazywanego odpornością połączenia. Elastyczność połączenia została wprowadzona w wersji EF Core 1.1.0.

Podstawową abstrakcją jest interfejs IExecutionStrategy. Strategia wykonywania dla programu SQL Server, w tym usługi Azure SQL, jest świadoma typów wyjątków, które można ponowić i ma rozsądne wartości domyślne dla maksymalnej liczby ponownych prób, opóźnienia między ponownymi próbami itd.

Przykłady

Poniższy kod umożliwia automatyczne ponawianie prób podczas konfigurowania obiektu DbContext, który reprezentuje sesję z bazą danych.

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

Poniższy kod przedstawia sposób wykonywania transakcji z automatycznym ponawianiem za pomocą strategii wykonywania. Transakcja jest definiowana w delegacie. Jeśli wystąpi błąd przejściowy, strategia wykonywania ponownie wywoła delegata.

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

Usługi Azure Storage obejmują magazyn obiektów blob, pliki i kolejki magazynu.

Obiekty blob, kolejki i pliki

Klasa ClientOptions jest typem podstawowym dla wszystkich typów opcji klienta i uwidacznia różne typowe opcje klienta, takie jak Diagnostyka, Ponawianie, Transport. Aby udostępnić opcje konfiguracji klienta służące do nawiązywania połączenia z usługą Azure Queue, Blob i File Storage, należy użyć odpowiedniego typu pochodnego. W następnym przykładzie użyjesz klasy QueueClientOptions (pochodzącej z klasy ClientOptions), aby skonfigurować klienta w celu nawiązania połączenia z usługą Azure Queue Service. Właściwość Ponów próbę to zestaw opcji, które można określić, aby wpływać na sposób ponawiania prób i jak można ponowić próbę.

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);

Obsługa tabel

Uwaga

Pakiet Nuget WindowsAzure.Storage i pakiet Nuget Microsoft.Azure.Cosmos.Table zostały wycofane. Aby uzyskać informacje o obsłudze tabel platformy Azure, zobacz Pakiet Nuget Azure.Data.Tables

Mechanizm ponawiania prób

Biblioteka kliencka jest oparta na bibliotece Azure Core, która jest biblioteką udostępniającą usługi krzyżowe innym bibliotekom klienckim.

Istnieje wiele powodów, dla których awaria może wystąpić, gdy aplikacja kliencka próbuje wysłać żądanie sieciowe do usługi. Niektóre przykłady to przekroczenie limitu czasu, awarie infrastruktury sieciowej, usługa odrzucania żądania z powodu ograniczenia/zajętości, zakończenia wystąpienia usługi z powodu skalowania usługi w dół, wystąpienie usługi będzie w dół, które zostanie zastąpione inną wersją, awaria usługi z powodu nieobsługiwanego wyjątku itd. Oferując wbudowany mechanizm ponawiania prób (z domyślną konfiguracją, którą użytkownik może zastąpić), nasze zestawy SDK i aplikacja użytkownika stają się odporne na tego rodzaju błędy. Należy pamiętać, że niektóre usługi pobierają rzeczywiste pieniądze za każde żądanie, a więc konsumenci powinni mieć możliwość całkowitego wyłączenia ponownych prób, jeśli wolą zaoszczędzić pieniądze na odporności.

Konfiguracja zasad

Zasady ponawiania prób są konfigurowane programowo. Konfiguracja jest oparta na klasie RetryOption. Element TableClientOptions dziedziczony z elementu ClientOptions jest atrybutem

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

W poniższych tabelach przedstawiono możliwości wbudowanych zasad ponawiania prób.

Ponów próbęOpcje

Ustawienie	Znaczenie
Opóźnienie	Opóźnienie między próbami ponawiania próby dla stałego podejścia lub opóźnieniem, na którym mają być oparte obliczenia na podstawie podejścia opartego na wycofywaniu. Jeśli usługa udostępnia nagłówek odpowiedzi Po ponowieniu próby, następne ponowienie próby zostanie opóźnione o czas trwania określony przez wartość nagłówka.
MaxDelay	Maksymalne dopuszczalne opóźnienie między próbami ponawiania próby, gdy usługa nie udostępnia nagłówka odpowiedzi Ponów próbę po. Jeśli usługa udostępnia nagłówek odpowiedzi Po ponowieniu próby, następne ponowienie próby zostanie opóźnione o czas trwania określony przez wartość nagłówka.
Tryb	Podejście do obliczania opóźnień ponawiania prób.
NetworkTimeout	Limit czasu zastosowany do poszczególnych operacji sieciowych.

RetryMode

Ustawienie	Znaczenie
Wykładniczy	Próby ponawiania będą opóźniać w oparciu o strategię wycofywania, w której każda próba zwiększy czas oczekiwania przed ponowną próbą.
MaxDelay	Próby ponawiania są wykonywane w ustalonych odstępach czasu; każde opóźnienie jest stałym czasem trwania.

Telemetria

Najprostszym sposobem wyświetlenia dzienników jest włączenie rejestrowania konsoli. Aby utworzyć odbiornik dziennika zestawu Azure SDK, który generuje komunikaty do konsoli, użyj metody AzureEventSourceListener.CreateConsoleLogger.

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

Przykłady

Wykonanie poniższego przykładu kodu z zamknięciem emulatora magazynu umożliwi nam wyświetlanie informacji o ponownych próbach w konsoli programu .

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}.");
        }
    }
}

Ogólne wskazówki dotyczące interfejsu REST i ponawiania prób

Podczas uzyskiwania dostępu do usług platformy Azure lub innych firm należy wziąć pod uwagę następujące kwestie:

• Skorzystaj z systematycznego podejścia do zarządzania ponowieniami, na przykład kodu wielokrotnego wykorzystania, aby możliwe było zastosowanie spójnej metodologii w ramach wszystkich klientów i rozwiązań.

• Rozważ użycie struktury ponawiania prób, takiej jak Polly , aby zarządzać ponownymi próbami, jeśli usługa docelowa lub klient nie ma wbudowanego mechanizmu ponawiania prób. Ułatwi to zaimplementowanie stałego sposobu ponawiania, a także zapewni odpowiednią strategię domyślnego ponawiania dla usługi docelowej. Może jednak być konieczne utworzenie niestandardowego kodu ponawiania prób dla usług, które mają niestandardowe zachowanie, które nie polegają na wyjątkach, aby wskazać błędy przejściowe lub jeśli chcesz użyć odpowiedzi Retry-Response w celu zarządzania zachowaniem ponawiania prób.

• Logika wykrywania błędów przejściowych zależy od rzeczywistego interfejsu API klienta używanego w celu wywołania usługi REST. Niektórzy klienci, tacy jak nowsza klasa HttpClient , nie zgłaszają wyjątków dla zakończonych żądań z kodem stanu HTTP, który nie zakończył się powodzeniem.

• Kod stanu HTTP zwrócony przez usługę może pomóc określić, czy błąd jest przejściowy. Może być konieczne przeanalizowanie wyjątków wygenerowanych przez klienta lub struktury ponawiania, aby uzyskać dostęp do kodu stanu lub określić równoważny typ wyjątku. Następujące kody HTTP zazwyczaj oznaczają, że ponowienie próby jest wskazane do przeprowadzenia:

  • 408 — limit czasu żądania
  • 429 Zbyt wiele żądań
  • 500 Wewnętrzny błąd serwera
  • 502 Niewłaściwa brama
  • 503 — usługa niedostępna
  • 504 — limit czasu bramy

• Jeśli logika ponowień opiera się na wyjątkach, poniższe elementy zazwyczaj wskazują na błąd przejściowy świadczący o tym, że nawiązanie połączenia nie było możliwe:

  • WebExceptionStatus.ConnectionClosed
  • WebExceptionStatus.ConnectFailure
  • WebExceptionStatus.Timeout
  • WebExceptionStatus.RequestCanceled

• Jeśli stan usługi wskazuje jej niedostępność, usługa może wskazywać odpowiednie opóźnienie przed wykonaniem ponowienia w nagłówku odpowiedzi Ponawianie po lub innym nagłówku niestandardowym. Usługi mogą również wysłać dodatkowe informacje jako nagłówki niestandardowe lub informacje osadzone w treści odpowiedzi.

• Nie należy ponawiać próby dla kodów stanu reprezentujących błędy klienta (błędy w zakresie 4xx) z wyjątkiem limitu czasu żądania 408 i 429 zbyt wielu żądań.

• Warto dokładnie przetestować strategie i mechanizmy ponowień pod względem wielu warunków, takich jak różne stany sieci i różne obciążenia systemu.

Strategie dotyczące ponawiania prób

Poniżej przedstawiono typowe rodzaje interwałów strategii ponawiania:

• Wykładnik. Zasady ponawiania, które wykonują określoną liczbę ponownych prób, przy użyciu metody wycofywania wykładniczego losowego w celu określenia interwału między ponownymi próbami. Na przykład:

  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);
  

• Przyrostowe. Strategia ponawiania z określoną liczbą ponownych prób i przyrostowym interwałem czasu między ponownymi próbami. Na przykład:

  retryInterval = TimeSpan.FromMilliseconds(this.initialInterval.TotalMilliseconds +
                  (this.increment.TotalMilliseconds * currentRetryCount));
  

• LinearRetry. Zasady ponawiania, które wykonują określoną liczbę ponownych prób przy użyciu określonego stałego interwału czasu między ponownymi próbami. Na przykład:

  retryInterval = this.deltaBackoff;
  

Obsługa błędu przejściowego w usłudze Polly

Polly to biblioteka do programowego obsługiwania ponownych prób i strategii wyłącznika . Projekt Polly jest częścią platformy .NET Foundation. W przypadku usług, w których klient nie obsługuje natywnie ponownych prób, polly jest prawidłową alternatywą i unika konieczności pisania niestandardowego kodu ponawiania, który może być trudny do poprawnego zaimplementowania. Polly umożliwia również śledzenie pojawiających się błędów, co z kolei pozwala rejestrować ponawiane próby.

Następne kroki

• Odporność połączenia programu Entity Framework