Sdílet prostřednictvím

Pokyny k opakování pro služby Azure

  • Článek

Mechanismus opakování obsahuje většina služeb Azure a klientských sad SDK. Tyto mechanismy se ale liší, protože každá služba má jiné vlastnosti a požadavky, takže každý mechanismus opakování je vyladěný pro konkrétní službu. Tato příručka shrnuje funkce mechanismu opakování pro většinu služeb Azure a obsahuje informace, které vám pomůžou používat, přizpůsobovat nebo rozšířit mechanismus opakování pro tuto službu.

Obecné pokyny ke zpracování přechodných chyb a k opakování připojení a operací u služeb a prostředků najdete v pokynech pro opakování.

Funkce opakování pro služby Azure popisované v těchto pokynech shrnuje následující tabulka.

Služba Funkce opakování Konfigurace zásad Scope Telemetrické funkce
Microsoft Entra ID Nativní v knihovně MSAL Vložené do knihovny MSAL Interní Nic
Azure Cosmos DB Nativní ve službě Nekonfigurovatelné Globální TraceSource
Data Lake Store Nativní v klientovi Nekonfigurovatelné Jednotlivé operace Nic
Event Hubs Nativní v klientovi Programová Klient Nic
IoT Hub Nativní v klientské sadě SDK Programová Klient Nic
Azure Cache for Redis Nativní v klientovi Programová Klient TextWriter
Vyhledat Nativní v klientovi Programová Klient Trasování událostí pro Windows (ETW) nebo vlastní
Service Bus Nativní v klientovi Programová Namespace Manager, Messaging Factory a klient Trasování událostí pro Windows
Service Fabric Nativní v klientovi Programová Klient Nic
SQL Database s ADO.NET Polly Deklarativní a programová Jednotlivé příkazy nebo bloky kódu Vlastní
SQL Database s Entity Framework Nativní v klientovi Programová Globální na doménu aplikace Nic
SQL Database s Entity Framework Core Nativní v klientovi Programová Globální na doménu aplikace Nic
Úložiště Nativní v klientovi Programová Klient a jednotlivé operace TraceSource

Poznámka:

U většiny předdefinovaných mechanismů opakování v Azure se v současné době nepoužívá jiná zásada opakování pro různé typy chyb nebo výjimek. Měli byste nakonfigurovat zásadu, která poskytuje optimální průměrný výkon a dostupnost. Jedna z možností, jak zásady vyladit, je určit typ přechodných chyb, ke kterým dochází.

Microsoft Entra ID

Microsoft Entra ID je komplexní cloudové řešení pro správu identit a přístupu, které kombinuje základní adresářové služby, pokročilé zásady správného řízení identit, zabezpečení a správu přístupu k aplikacím. Microsoft Entra ID také nabízí vývojářům platformu pro správu identit, která poskytuje řízení přístupu k aplikacím na základě centralizovaných zásad a pravidel.

Poznámka:

Pokyny k opakování koncových bodů identity spravované služby najdete v tématu Použití identity spravované služby (MSI) virtuálního počítače Azure k získání tokenu.

Mechanismus opakování

Existuje integrovaný mechanismus opakování pro Microsoft Entra ID v knihovně Microsoft Authentication Library (MSAL). Pokud se chcete vyhnout neočekávaným uzamčením, doporučujeme, aby knihovny třetích stran a kód aplikace nezopakovály neúspěšná připojení, ale povolte službě MSAL zpracování opakovaných pokusů.

Pokyny k použití opakování

Při používání MICROSOFT Entra ID zvažte následující pokyny:

  • Pokud je to možné, použijte knihovnu MSAL a integrovanou podporu opakování.
  • Pokud používáte rozhraní REST API pro ID Microsoft Entra, zkuste operaci zopakovat, pokud je kód výsledku 429 (Příliš mnoho požadavků) nebo chyba v rozsahu 5xx. Neprovádějte žádné další chyby.
  • V případě chyb 429 opakujte akci pouze po uplynutí doby uvedené v hlavičce Opakovat až po .
  • V případě chyb 5xx použijte exponenciální zpětné vypnutí s prvním opakováním aspoň 5 sekund po odpovědi.
  • Zkuste to znovu u chyb jiných než 429 a 5xx.

Další kroky

Azure Cosmos DB

Azure Cosmos DB je plně spravovaná vícemodelová databáze, která podporuje data JSON bez schématu. Nabízí konfigurovatelný a spolehlivý výkon, nativní zpracování transakcí JavaScript a je vytvořená pro cloud s pružným škálováním.

Mechanismus opakování

Sady SDK služby Azure Cosmos DB se automaticky opakují v určitých chybových podmínkách a u uživatelských aplikací se doporučuje mít vlastní zásady opakování. Úplný seznam chybových podmínek a čas opakování najdete v průvodci návrhem odolných aplikací pomocí sad SDK služby Azure Cosmos DB.

Telemetrie

V závislosti na jazyce vaší aplikace se diagnostika a telemetrie zveřejňují jako protokoly nebo upřednostněné vlastnosti odpovědí na operaci. Další informace najdete v části Zachycení diagnostiky v sadě Azure Cosmos DB C# SDK a sadě Java SDK služby Azure Cosmos DB.

Data Lake Store

Data Lake Storage Gen2 představuje Azure Storage základ pro vytváření podnikových datových jezer v Azure. Data Lake Storage Gen2 umožňuje snadnou správu obrovských objemů dat.

Klientská knihovna Azure Storage Files Data Lake zahrnuje všechny možnosti potřebné k tomu, aby vývojáři, datoví vědci a analytici mohli ukládat data libovolné velikosti, tvaru a rychlosti a provádět všechny typy zpracování a analýzy napříč platformami a jazyky.

Mechanismus opakování

DataLakeServiceClient umožňuje manipulovat s prostředky služby Azure Data Lake a systémy souborů. Účet úložiště poskytuje obor názvů nejvyšší úrovně pro službu Data Lake. Při vytváření klienta můžete poskytnout možnosti konfigurace klienta pro připojení ke službě Azure Data Lake (DataLakeClientOptions). DataLakeClientOptions obsahuje vlastnost Retry (zděděná z Azure.Core.ClientOptions), kterou je možné nakonfigurovat (třída RetryOptions).

Telemetrie

Monitorování využití a výkonu služby Azure Storage je důležitou součástí zprovoznění vaší služby. Mezi příklady patří časté operace, operace s vysokou latencí nebo operace, které způsobují omezování na straně služby.

Veškerá telemetrie pro váš účet úložiště je dostupná prostřednictvím protokolů azure Storage ve službě Azure Monitor. Tato funkce integruje váš účet úložiště se službou Log Analytics a event Hubs a zároveň umožňuje archivovat protokoly do jiného účtu úložiště. Úplný seznam metrik a protokolů prostředků a jejich přidruženého schématu najdete v referenčních informacích k monitorování služby Azure Storage.

Event Hubs

Azure Event Hubs je služba pro příjem telemetrie hyperškálování, která shromažďuje, transformuje a ukládá miliony událostí.

Mechanismus opakování

Chování při opakování je v klientské knihovně Azure Event Hubs řízené vlastností RetryPolicy ve třídě EventHubClient. Výchozí zásady se opakuje s exponenciálním zpochybněním, když Azure Event Hubs vrátí přechodné nebo přechodné EventHubsException OperationCanceledException. Výchozí zásadou opakování pro službu Event Hubs je opakování až 9krát s exponenciálním časem zpětného vypnutí až 30 sekund.

Příklad

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

Další kroky

Klientská knihovna služby Azure Event Hubs pro .NET

IoT Hub

Azure IoT Hub je služba pro připojení, monitorování a správu zařízení pro vývoj aplikací Internetu věcí (IoT).

Mechanismus opakování

Sada SDK zařízení Azure IoT dokáže detekovat chyby v síti, protokolu nebo aplikaci. Na základě typu chyby sada SDK zkontroluje, jestli je potřeba provést opakování. Pokud je chyba obnovitelná, sada SDK začne opakovat pomocí nakonfigurovaných zásad opakování.

Výchozí zásada opakování je exponenciální zpět s náhodným zpožděním, ale dá se nakonfigurovat.

Konfigurace zásad

Konfigurace zásad se liší podle jazyka. Další informace najdete v tématu Konfigurace zásad opakování služby IoT Hub.

Další kroky

Azure Cache for Redis

Azure Cache for Redis je rychlá služba pro přístup k datům a služba mezipaměti s nízkou latencí založená na oblíbené opensourcové mezipaměti Redis. Je zabezpečená, spravovaná Microsoftem a je přístupná z jakékoli aplikace v Azure.

Pokyny v této části vycházejí z předpokladu, že se pro přístup k mezipaměti používá klient StackExchange.Redis. Seznam dalších vhodných klientů můžete najít na webu Redis. Tito klienti můžou mít jiné mechanismy opakování.

Klient StackExchange.Redis používá multiplexování prostřednictvím jediného připojení. Doporučuje se vytvořit instanci klienta při spuštění aplikace a používat tuto instanci pro všechny operace s mezipamětí. Z tohoto důvodu se připojení k mezipaměti provede jenom jednou, takže všechny pokyny v této části se týkají zásad opakování pro toto počáteční připojení – ne pro jednotlivé operace přistupující k mezipaměti.

Mechanismus opakování

Klient StackExchange.Redis používá třídu správce připojení, která je nakonfigurována prostřednictvím sady možností, včetně:

  • ConnectRetry. Počet opakovaných pokusů při neúspěšném připojení k mezipaměti.
  • ReconnectRetryPolicy. Používaná strategie opakování.
  • ConnectTimeout. Maximální doba čekání v milisekundách.

Konfigurace zásad

Zásady opakování se konfigurují programově – nastavením možností pro klienta před připojováním k mezipaměti. Dá se to udělat tak, že se vytvoří instance třídy ConfigurationOptions, naplní se její vlastnosti a předá se metodě Connect.

Předdefinované třídy podporují lineární (konstantní) zpoždění a exponenciální regresi s náhodnými intervaly opakování. Také můžete vytvořit vlastní zásady opakování – implementací rozhraní IReconnectRetryPolicy.

V následujícím příkladu nakonfigurujeme strategii opakování s exponenciální regresí.

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

Možnosti můžete případně zadat jako řetězec a tento řetězec předat metodě Connect. ReconnectRetryPolicy vlastnost nelze nastavit tímto způsobem, pouze prostřednictvím kódu.

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

Možnosti můžete také zadat přímo při připojení k mezipaměti.

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

Další informace najdete v dokumentaci StackExchange.Redis v části o konfiguraci Stack Exchange Redis.

Následující tabulka ukazuje výchozí nastavení pro předdefinované zásady opakování.

Kontext Nastavení Výchozí hodnota
(v. 1.2.2)		 Význam
ConfigurationOptions ConnectRetry

ConnectTimeout

SyncTimeout

ReconnectRetryPolicy		 3

Maximálně 5000 ms plus SyncTimeout
1000

LinearRetry 5000 ms		 Počet opakovaných pokusů o připojení během počáteční operace připojení.
Časový limit (ms) pro operace připojení. Není to zpoždění mezi opakovanými pokusy.
Doba (ms) pro synchronní operace.

Opakování po 5000 ms.

Poznámka:

U synchronních operací může SyncTimeout prodlužovat celkovou latenci, když ale nastavíte tuto hodnotu příliš nízkou, může to způsobit nadměrná vypršení časových limitů. Další informace najdete v tématu Řešení potíží se službou Azure Cache for Redis. Obecně doporučujeme používat místo synchronních operací asynchronní. Další informace najdete v tématu Kanály a multiplexery.

Pokyny k použití opakování

Při používání služby Azure Cache for Redis zvažte následující pokyny:

  • Klient StackExchange Redis spravuje vlastní opakované pokusy, ale jenom při navazování připojení při počátečním spuštění aplikace. Můžete nakonfigurovat časový limit připojení, počet pokusů o opakování a čas mezi opakovanými pokusy o navázání tohoto připojení, ale zásada opakování se nevztahuje na operace s mezipamětí.
  • Místo použití velkého počtu opakovaných pokusů zvažte nouzové přepnutí na přístup k původnímu zdroji dat.

Telemetrie

Můžete použít TextWriter a shromažďovat informace o připojeních (ale ne o jiných operacích).

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

Níže je uvedený příklad vygenerovaného výstupu.

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

Příklady

Následující příklad kódu konfiguruje konstantní (lineární) zpoždění mezi opakovanými pokusy při inicializaci klienta StackExchange.Redis. Tento příklad ukazuje, jak nastavit konfiguraci pomocí instance 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;
                }
            }
        }
    }
}

Následující příklad ukazuje, jak nastavit konfiguraci zadáním možností ve formě řetězce. Časový limit připojení je maximální doba čekání na připojení k mezipaměti, není to zpoždění mezi opakovanými pokusy. ReconnectRetryPolicy vlastnost lze nastavit pouze kódem.

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

Další informace najdete na webu projektu v článku o konfiguraci.

Další kroky

Služba Azure Search se dá použít k přidání výkonných a důmyslných možností vyhledávání na web nebo do aplikace, k rychlému a snadnému vyladění výsledků hledání a k vytvoření složitých, jemně vyladěných modelů řazení.

Mechanismus opakování

Sada Azure SDK pro .NET obsahuje klientskou knihovnu Azure.Search.Documents od týmu sady Azure SDK, která je funkčně ekvivalentní předchozí klientské knihovně Microsoft.Azure.Search.

Chování opakování v Microsoft.Azure.Search je řízeno metodou SetRetryPolicy ve třídách SearchServiceClient a SearchIndexClient. Když služba Azure Search vrátí odpověď 5xx nebo 408 (Časový limit žádosti), výchozí zásady opakují pokus s exponenciální regresí.

Chování opakování ve službě Azure.Search.Documents řídí SearchClientOptions (je součástí konstruktoru SearchClient) ve vlastnosti Retry, která patří do třídy Azure.Core.RetryOptions(kde jsou k dispozici všechny konfigurace).

Telemetrie

Trasujte pomocí Trasování událostí pro Windows nebo si zaregistrujte vlastního zprostředkovatele trasování. Další informace najdete v dokumentaci k AutoRestu.

Service Bus

Service Bus je cloudová platforma zasílání zpráv, která umožňuje volně spojenou výměnu zpráv s lepší škálovatelností a odolností součástí aplikací, ať už je hostovaná v cloudu nebo místně.

Mechanismus opakování

Obor názvů a některé podrobnosti konfigurace závisí na tom, který balíček klientské sady SDK služby Service Bus se používá:

Balíček Popis Obor názvů
Azure.Messaging.ServiceBus Klientská knihovna služby Azure Service Bus pro .NET Azure.Messaging.ServiceBus
WindowsAzure.ServiceBus Tento balíček je starší klientskou knihovnou služby Service Bus. Vyžaduje rozhraní .NET Framework 4.5.2. Microsoft.Azure.ServiceBus

Pokyny k použití opakování

Vlastnost ServiceBusRetryOptions určuje možnosti opakování objektu ServiceBusClient :

Nastavení Default value Význam
CustomRetryPolicy Vlastní zásada opakování, která se má použít místo hodnot jednotlivých možností.
Zpoždění 0,8 sekundy Zpoždění mezi opakovanými pokusy o pevný přístup nebo zpožděním, na kterém se mají založit výpočty pro přístup založený na zpětném odpočtu.
MaxDelay 60 sekund Maximální přípustné zpoždění mezi opakovanými pokusy.
MaxRetries 3 Maximální počet pokusů o opakování před zvážením přidružené operace, která selhala.
Režim Exponenciální Přístup k výpočtu zpoždění opakování.
TryTimeout 60 sekund Maximální doba trvání čekání na dokončení jednoho pokusu, ať už počáteční pokus nebo opakování.

Mode Nastavte vlastnost pro konfiguraci ServiceBusRetryMode s některou z těchto hodnot:

Vlastnost Hodnota Popis
Exponenciální 0 Pokusy o opakování se zpozdí na základě strategie zpětného odsunutí, kdy každý pokus zvýší dobu, po kterou čeká před opakováním.
Pevný 0 K opakovaným pokusům dochází v pevných intervalech; každé zpoždění je konzistentní doba trvání.

Příklad:

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 shromažďuje stejné druhy dat monitorování jako jiné prostředky Azure. Službu Azure Service Bus můžete monitorovat pomocí služby Azure Monitor.

Máte také různé možnosti odesílání telemetrie pomocí klientských knihoven Service Bus .NET.

Příklad

Následující příklad kódu ukazuje, jak balíček použít Azure.Messaging.ServiceBus k:

  • Nastavte zásadu opakování pro ServiceBusClient použití nové ServiceBusClientOptions.
  • Vytvořte novou zprávu s novou instancí ServiceBusMessage.
  • Odešlete zprávu do služby Service Bus pomocí ServiceBusSender.SendMessageAsync(message) metody.
  • Přijmout pomocí objektu ServiceBusReceiver, který jsou reprezentovány jako ServiceBusReceivedMessage objekty.
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);

Další kroky

Service Fabric

Při distribuci spolehlivých služeb v clusteru Service Fabric budete chráněni před většinou potenciálních přechodných chyb popisovaných v tomto článku. Některé přechodné chyby jsou ale přesto možné. Když například služba pojmenování obdrží žádost během změny směrování, vyvolá výjimku. Pokud stejná žádost přijde o 100 milisekund později, bude pravděpodobně úspěšná.

Service Fabric spravuje tento druh přechodné chyby interně. Při nastavování služeb můžete některá nastavení nakonfigurovat pomocí třídy OperationRetrySettings. Následující kód znázorňuje příklad. Ve většině případů by to nemělo být nutné a výchozí nastavení bude v pořádku.

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

Další kroky

SQL Database s využitím ADO.NET

SQL Database je hostovaná služba SQL Database dostupná v rozsahu velikostí a jako standardní (sdílená) i služba Premium (nesdílená).

Mechanismus opakování

SQL Database nemá předdefinovanou podporu opakovaných pokusů při přístupu pomocí ADO.NET. Pomocí návratových kódů žádostí se ale dá zjistit, proč žádost selhala. Další informace o omezování u SQL Database najdete v článku Limity prostředků Azure SQL Database. Seznam příslušných kódů chyb najdete v článku Kódy chyb SQL pro klientské aplikace SQL Database.

K implementaci opakovaných pokusů u SQL Database můžete použít knihovnu Polly. Další informace najdete v tématu Zpracování přechodných chyb pomocí Polly.

Pokyny k použití opakování

Když budete přistupovat k SQL Database pomocí ADO.NET, vezměte v úvahu následující pokyny:

  • Zvolte patřičnou možnost služby (sdílenou nebo premium službu). Sdílená instance může trpět prodlevami připojení delšími než obvykle a omezeními v důsledku použití dalšími tenanty sdíleného serveru. Pokud požadujete předvídatelný výkon a spolehlivé operace s nízkou latencí, zvažte volbu možnosti premium.
  • Zajistěte, aby opakované pokusy probíhaly v patřičné úrovni nebo rozsahu, abyste zabránili neidempotentním operacím způsobujícím nekonzistenci dat. V ideálním případě by všechny operace měly být idempotentní, aby se mohly opakovat bez rizika, že způsobí nekonzistenci. Pokud tomu tak není, měl by se opakovat na úrovni nebo oboru, který umožňuje vrácení všech souvisejících změn zpět v případě selhání jedné operace; Například v rámci transakčního oboru. Další informace najdete v článku Vrstva přístupu k datům u aplikace Cloud Service Fundamentals – zpracování přechodných chyb.
  • Strategie s pevným intervalem se nedoporučuje používat se službou Azure SQL Database s výjimkou interaktivních scénářů, kdy v krátkých intervalech existuje jen několik opakování. Místo toho zvažte použití exponenciální zpětné strategie pro většinu scénářů.
  • Při definování připojení zvolte vhodnou hodnotu časových limitů připojení a příkazů. Příliš krátký časový limit může u přetížené databáze vést k předčasným chybám. Příliš dlouhý časový limit může bránit správnému fungování logiky opakování, která bude příliš dlouho čekat, než zjistí neúspěšné připojení. Hodnota časového limitu je součástí koncové latence; efektivně se přidá do zpoždění opakování zadaného v zásadách opakování pro každý pokus o opakování.
  • Zavřete připojení po několika opakováních, i když použijete exponenciální zpětnou logiku opakování a zkuste operaci zopakovat na novém připojení. Vícenásobné opakování stejné operace u stejného připojení může přispívat k problémům s připojením. Příklad této techniky najdete v článku Vrstva přístupu k datům u aplikace Cloud Service Fundamentals – zpracování přechodných chyb.
  • Pokud se používá sdružování připojení (výchozí nastavení), je možné, že stejné připojení bude vybráno z fondu, a to i po zavření a opětovném otevření připojení. Pokud ano, technika k vyřešení je volání ClearPool metoda SqlConnection třídy označit připojení jako nereusovatelné. Mělo by se to ale udělat až po několika neúspěšných pokusech o připojení a jenom v případě určité kategorie přechodných selhání, například u vypršení časových limitů SQL (kód chyby -2) souvisejících s chybnými připojeními.
  • Pokud kód pro přístup k datům používá transakce iniciované jako instance TransactionScope, měla by logika opakování znovu otevřít připojení a iniciovat nový obor transakce. Z tohoto důvodu by měl blok opakovatelného kódu zahrnovat celý obor transakce.

Začít můžete s následujícím nastavením operací opakování. Tato nastavení jsou pro obecné účely a měli byste monitorovat operace a doladit hodnoty tak, aby vyhovovaly vašemu vlastnímu scénáři.

Kontext Ukázkový cíl E2E
maximální latence		 Strategie opakování Možnosti Hodnoty Jak to funguje
Interaktivní, uživatelské rozhraní
nebo popředí		 2 s FixedInterval Počet opakování
Interval opakování
První rychlé opakování		 3
500 ms
true		 Pokus 1 – zpoždění 0 s
Pokus 2 – zpoždění 500 ms
Pokus 3 – zpoždění 500 ms
Pozadí
nebo dávka		 30 s ExponentialBackoff Počet opakování
Min back-off
Max back-off
Delta back-off
První rychlé opakování		 5
0 s
60 s
2 s
false (nepravda)		 Pokus 1 – zpoždění 0 s
Pokus 2 – zpoždění ~2 s
Pokus 3 – zpoždění ~6 s
Pokus 4 – zpoždění ~14 s
Pokus 5 – zpoždění ~30 s

Poznámka:

Cílové hodnoty celkové latence předpokládají výchozí časový limit pro připojení ke službě. Pokud zadáte delší časové limity připojení, celková latence se pro každý opakovaný pokus prodlouží o tuto další dobu.

Příklady

Tato část ukazuje, jak můžete použít knihovnu Polly pro přístup k Azure SQL Database pomocí sady zásad opakování nakonfigurovaných v třídě Policy.

Následující kód ukazuje rozšiřující metodu u třídy SqlCommand, která volá ExecuteAsync s exponenciální regresí.

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

Tato asynchronní rozšiřující metoda se dá použít následovně.

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

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

Další kroky

SQL Database s využitím Entity Frameworku 6

SQL Database je hostovaná služba SQL Database dostupná v rozsahu velikostí a jako standardní (sdílená) i služba Premium (nesdílená). Entity Framework je objektově-relační mapovač, který umožňuje vývojářům na platformě .NET pracovat s relačními daty pomocí objektů specifických pro doménu. Šetří vývojářům práci, protože nemusejí psát většinu kódu pro přístup k datům.

Mechanismus opakování

Podpora opakování se poskytuje při přístupu ke službě SQL Database pomocí Entity Frameworku 6.0 a vyšší prostřednictvím mechanismu označovaného jako odolnost připojení / logika opakování. Hlavní funkce mechanismu opakování jsou:

  • Primární abstrakcí je rozhraní IDbExecutionStrategy. Toto rozhraní:
    • Definuje synchronní a asynchronní metody Execute .
    • Definuje třídy, které se dají použít přímo nebo se dají konfigurovat pro kontext databáze jako výchozí strategie, mapovat na název zprostředkovatele nebo mapovat na název zprostředkovatele a název serveru. Při konfiguraci pro kontext probíhají opakování na úrovni jednotlivých databázových operací, z nichž některé můžou být pro danou kontextovou operaci.
    • Definuje, kdy a jak se má neúspěšné připojení opakovat.
  • Zahrnuje několik předdefinovaných implementací rozhraní IDbExecutionStrategy :
    • Výchozí hodnota: Opakování se neopakuje.
    • Výchozí hodnota pro SLUŽBU SQL Database (automatická): Neopakuje se, ale kontroluje výjimky a zabalí je s návrhem, aby používala strategii služby SQL Database.
    • Výchozí hodnota pro SLUŽBU SQL Database: exponenciální (zděděná ze základní třídy) a logika detekce služby SQL Database.
  • Implementuje exponenciální regresní strategii, která zahrnuje náhodnost.
  • Předdefinované třídy opakování jsou stavové a nejsou bezpečné pro přístup z více vláken. Můžou ale být znovu použité po dokončení aktuální operace.
  • Pokud se překročí určený počet opakování, zabalí se výsledky do nové výjimky. Nedojde k bublině aktuální výjimky.

Konfigurace zásad

Opakování je podporované při přístupu k SQL Database pomocí technologie Entity Framework 6.0 nebo vyšší. Zásady opakování se konfigurují programově. Konfiguraci nelze změnit pro jednotlivé operace.

Když konfigurujete strategii pro kontext jako výchozí, určíte funkci, která vytvoří novou strategii na vyžádání. Následující kód ukazuje, jak můžete vytvořit třídu konfigurace opakování, která rozšiřuje základní třídu 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)));
  }
}

Tuto konfiguraci pak můžete při spuštění aplikace určit jako výchozí strategii opakování pro všechny operace pomocí metody SetConfiguration instance DbConfiguration. Entity Framework (EF) ve výchozím nastavení tuto třídu konfigurace automaticky zjistí a použije.

DbConfiguration.SetConfiguration(new BloggingContextConfiguration());

Třídu konfigurace opakování můžete pro kontext určit její anotací pomocí atributu DbConfigurationType. Pokud ale máte jenom jednu třídu konfigurace, Entity Framework ji použije, i když nebudete kontext anotovat.

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

Pokud potřebujete pro určité operace použít jiné strategie opakování nebo opakování zakázat, můžete vytvořit třídu konfigurace, která umožňuje pozastavit nebo přepnout strategie nastavením příznaku v CallContext. Tato třída konfigurace může tento příznak použít k přepnutí strategií nebo k zákazu vámi poskytnuté strategie a k použití výchozí strategie. Další informace naleznete v tématu Pozastavení strategie provádění (EF6 dále).

Další možností, jak používat pro jednotlivé operace zvláštní strategie opakování, je vytvoření instance požadované třídy strategie a předání potřebných nastavení pomocí parametrů. Pak vyvoláte její metodu 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()
);

Nejjednodušší způsob použití třídy DbConfiguration je její umístění ve stejném sestavení, ve kterém je třída DbContext. To ale není vhodné, pokud se vyžaduje stejný kontext v různých scénářích, jako jsou různé interaktivní strategie a strategie opakování na pozadí. Pokud se různé kontexty provádějí v samostatných doménách aplikace, můžete využít předdefinovanou podporu k určení tříd konfigurace v konfiguračním souboru nebo provést nastavení explicitně pomocí kódu. Pokud se různé kontexty musí provádět ve stejné doméně aplikace, bude nutné vlastní řešení.

Další informace najdete v tématu Konfigurace založená na kódu (EF6 dále).

Následující tabulka ukazuje výchozí nastavení pro předdefinované zásady opakování při použití EF6.

Nastavení Default value Význam
Zásady Exponenciální Exponenciální regrese.
MaxRetryCount 5 Maximální počet opakování.
MaxDelay 30 sekund Maximální zpoždění mezi opakovanými pokusy. Tato hodnota nemá vliv na výpočet řady zpoždění. Jenom definuje horní mez.
DefaultCoefficient 1 sekunda Koeficient pro exponenciální regresní výpočet. Tuto hodnotu nelze měnit.
DefaultRandomFactor 1,1 Násobitel používaný k přidání náhodného zpoždění ke každé položce. Tuto hodnotu nelze měnit.
DefaultExponentialBase 2 Násobitel používaný k výpočtu dalšího zpoždění. Tuto hodnotu nelze měnit.

Pokyny k použití opakování

Když budete přistupovat k SQL Database pomocí EF6, vezměte v úvahu následující pokyny:

  • Zvolte patřičnou možnost služby (sdílenou nebo premium službu). Sdílená instance může trpět prodlevami připojení delšími než obvykle a omezeními v důsledku použití dalšími tenanty sdíleného serveru. Pokud požadujete předvídatelný výkon a spolehlivé operace s nízkou latencí, zvažte volbu možnosti premium.

  • Pro použití se službou Azure SQL Database se nedoporučuje strategie s pevným intervalem. Místo ní použijte exponenciální regresní strategii, protože služba může být přetížená a delší prodlevy jí dají více času na zotavení.

  • Při definování připojení zvolte vhodnou hodnotu časových limitů připojení a příkazů. Časový limit založte na návrhu obchodní logiky a testování. Tuto hodnotu budete možná muset v průběhu času měnit, jak se budou měnit objemy dat nebo obchodní procesy. Příliš krátký časový limit může u přetížené databáze vést k předčasným chybám. Příliš dlouhý časový limit může bránit správnému fungování logiky opakování, která bude příliš dlouho čekat, než zjistí neúspěšné připojení. Hodnota časového limitu je součástí koncové latence, i když nemůžete snadno určit, kolik příkazů se spustí při ukládání kontextu. Výchozí časový limit můžete změnit nastavením vlastnosti CommandTimeout instance DbContext.

  • Entity Framework podporuje konfigurace definované v konfiguračních souborech. Kvůli maximální flexibilitě v Azure byste ale měli zvážit programové vytvoření konfigurace v rámci aplikace. Konkrétní parametry zásad opakování, jako třeba počet opakování nebo intervaly opakování, můžou být uložené v konfiguračním souboru služby. V době běhu aplikace můžou být použité k vytvoření patřičných zásad. Tak je možné nastavení změnit bez restartování aplikace.

Začít můžete s následujícím nastavením operací opakování. Prodlevu mezi opakovanými pokusy nemůžete určit (je opravená a vygenerovaná jako exponenciální sekvence). Můžete určit jenom maximální hodnoty, jak je ukázáno níže (pokud nevytvoříte vlastní strategii opakování). Tato nastavení jsou pro obecné účely a měli byste monitorovat operace a doladit hodnoty tak, aby vyhovovaly vašemu vlastnímu scénáři.

Kontext Ukázkový cíl E2E
maximální latence		 Zásady opakování Možnosti Hodnoty Jak to funguje
Interaktivní, uživatelské rozhraní
nebo popředí		 2 sekundy Exponenciální MaxRetryCount
MaxDelay		 3
750 ms		 Pokus 1 – zpoždění 0 s
Pokus 2 – zpoždění 750 ms
Pokus 3 – zpoždění 750 ms
Pozadí
nebo dávka		 30 sekund Exponenciální MaxRetryCount
MaxDelay		 5
12 sekund		 Pokus 1 – zpoždění 0 s
Pokus 2 – zpoždění ~1 s
Pokus 3 – zpoždění ~3 s
Pokus 4 – zpoždění ~7 s
Pokus 5 – zpoždění 12 s

Poznámka:

Cílové hodnoty celkové latence předpokládají výchozí časový limit pro připojení ke službě. Pokud zadáte delší časové limity připojení, celková latence se pro každý opakovaný pokus prodlouží o tuto další dobu.

Příklady

Následující příklad kódu definuje jednoduché řešení přístupu k datům, které používá Entity Framework. Nastaví zvláštní strategii opakování definováním instance třídy s názvem BlogConfiguration, která rozšiřuje 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();
            }
        }
    }
}

Další příklady použití mechanismu opakování Entity Framework najdete v logice odolnosti připojení nebo opakování.

SQL Database s využitím Entity Framework Core

Entity Framework Core je objektově-relační mapovač, který umožňuje vývojářům na platformě .NET Core pracovat s daty pomocí objektů specifických pro doménu. Šetří vývojářům práci, protože nemusejí psát většinu kódu pro přístup k datům. Tato verze Entity Framework byla napsaná od základu – nezdědila automaticky všechny funkce EF6.x.

Mechanismus opakování

Podpora opakování se poskytuje při přístupu ke službě SQL Database pomocí Entity Framework Core prostřednictvím mechanismu označovaného jako odolnost připojení. Odolnost připojení byla zavedená v EF Core 1.1.0.

Primární abstrakcí je rozhraní IExecutionStrategy. Strategie provádění SQL Serveru, včetně Azure SQL, si uvědomuje typy výjimek, které je možné opakovat, a má rozumné výchozí hodnoty pro maximální počet opakování, zpoždění mezi opakováními atd.

Příklady

Následující kód umožní automatické opakování pokusů – při konfiguraci objektu DbContext, který reprezentuje relaci s databází.

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

Následující kód ukazuje, jak se provádí transakce s automatickým opakováním pokusů – s použitím strategie provádění. Transakce je definovaná v delegátovi. Pokud dojde k přechodnému selhání, strategie provádění znovu vyvolá delegáta.

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

Mezi služby Azure Storage patří úložiště objektů blob, soubory a fronty úložiště.

Objekty blob, fronty a soubory

Třída ClientOptions je základním typem pro všechny typy možností klienta a zveřejňuje různé běžné možnosti klienta, jako je Diagnostika, Opakování, Přenos. Pokud chcete poskytnout možnosti konfigurace klienta pro připojení ke službě Azure Queue, Blob a File Storage, musíte použít odpovídající odvozený typ. V dalším příkladu použijete třídu QueueClientOptions (odvozenou z ClientOptions) ke konfiguraci klienta pro připojení ke službě Azure Queue Service. Vlastnost Opakovat je sada možností, které lze zadat, aby ovlivnily způsob opakování pokusů a způsob, jakým je možné opakovat selhání.

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

Podpora tabulek

Poznámka:

Balíček NuGet WindowsAzure.Storage a Balíček NuGet Microsoft.Azure.Cosmos.Table jsou zastaralé. Podpora tabulek Azure najdete v balíčku NuGet Azure.Data.Tables.

Mechanismus opakování

Klientská knihovna je založená na knihovně Azure Core, což je knihovna, která poskytuje průřezové služby dalším klientským knihovnám.

K selhání může dojít z mnoha důvodů, když se klientská aplikace pokusí odeslat žádost o síť do služby. Mezi příklady patří vypršení časového limitu, selhání síťové infrastruktury, odmítnutí žádosti kvůli omezování nebo zaneprázdnění, ukončení instance služby kvůli vertikálnímu snížení kapacity služby, snížení instance služby, která se má nahradit jinou verzí, chybovým ukončením služby kvůli neošetřené výjimce atd. Díky nabídce integrovaného mechanismu opakování (s výchozí konfigurací může příjemce přepsat) se naše sady SDK a aplikace příjemce stanou odolnými vůči těmto druhům selhání. Upozorňujeme, že některé služby účtují skutečné peníze za každou žádost, a proto by uživatelé měli být schopni zakázat opakované pokusy zcela, pokud dávají přednost úspoře peněz oproti odolnosti.

Konfigurace zásad

Zásady opakování se konfigurují programově. Konfigurace je založená na třídě RetryOption. Atribut TableClientOptions zděděný z ClientOptions

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

Následující tabulky ukazují možnosti integrovaných zásad opakování.

RetryOption

Nastavení Význam
Zpoždění Zpoždění mezi opakovanými pokusy o pevný přístup nebo zpožděním, na kterém se mají založit výpočty pro přístup založený na zpětném odpočtu. Pokud služba poskytuje hlavičku odpovědi Opakovat po, další opakování bude zpožděno o dobu trvání určenou hodnotou hlavičky.
MaxDelay Maximální přípustné zpoždění mezi pokusy o opakování v případech, kdy služba neposkytuje hlavičku odpovědi Opakovat až po. Pokud služba poskytuje hlavičku odpovědi Opakovat po, další opakování bude zpožděno o dobu trvání určenou hodnotou hlavičky.
Režim Přístup k výpočtu zpoždění opakování.
NetworkTimeout Časový limit použitý u jednotlivých síťových operací.

RetryMode

Nastavení Význam
Exponenciální Pokusy o opakování se zpozdí na základě strategie zpětného odsunutí, kdy každý pokus zvýší dobu, po kterou čeká před opakováním.
MaxDelay K opakovaným pokusům dochází v pevných intervalech; každé zpoždění je konzistentní doba trvání.

Telemetrie

Nejjednodušší způsob, jak zobrazit protokoly, je povolit protokolování konzoly. K vytvoření naslouchacího procesu protokolu sady Azure SDK, který odesílá zprávy do konzoly, použijte metodu AzureEventSourceListener.CreateConsoleLogger.

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

Příklady

Spuštění následujícího příkladu kódu s vypnutým emulátorem úložiště nám umožní zobrazit informace o opakovaných opakováních v konzole.

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

Obecné pokyny pro REST a opakování

Při přístupu ke službám Azure nebo třetích stran vezměte v úvahu následující skutečnosti:

  • Při správě opakovaných pokusů používejte systémový přístup, například opakovaně použitelný kód, abyste mohli u všech klientů a řešení použít jednotnou metodologii.

  • Pokud cílová služba nebo klient nemá žádný integrovaný mechanismus opakování, zvažte použití architektury opakování, jako je Polly . To vám umožní implementovat konzistentní chování opakování a může poskytnout vhodnou výchozí strategii opakování pro cílovou službu. Možná ale budete muset vytvořit vlastní kód opakování pro služby, které nemají nestandardní chování, které nespoléhá na výjimky, které indikují přechodné selhání, nebo pokud chcete ke správě chování opakování použít odpověď retry-Response .

  • Logika zjišťování přechodných chyb bude záviset na skutečném rozhraní API klienta, které budete používat k voláním REST. Někteří klienti, jako je novější třída HttpClient , nevyvolají výjimky pro dokončené požadavky se stavovým kódem HTTP, který není úspěšný.

  • Stavový kód HTTP vrácený službou umožňuje signalizovat, jestli je selhání přechodné. Nejspíš budete muset zkoumat výjimky generované klientem nebo architekturou opakování, abyste získali přístup ke stavovému kódu nebo určili ekvivalentní typ výjimky. Následující kódy HTTP obvykle signalizují, že je opakování vhodné:

    • 408 – Časový limit žádosti
    • 429 – Příliš mnoho požadavků
    • 500 – Vnitřní chyba serveru
    • 502 – Chybná brána
    • 503 – Nedostupná služba
    • 504 – Časový limit brány

  • Pokud máte logiku opakování založenou na výjimkách a nedá se navázat připojení, následující výjimky obvykle signalizují přechodné selhání:

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

  • V případě stavu Nedostupná služba může služba indikovat patřičné zpoždění před opakováním v hlavičce odpovědi Retry-After nebo v jiné vlastní hlavičce. Služby také můžou odesílat další informace jako vlastní hlavičky nebo vložené v obsahu odpovědi.

  • Nepokoušejte se opakovat u stavových kódů představujících chyby klienta (chyby v rozsahu 4xx) s výjimkou časového limitu 408 požadavků a 429 Příliš mnoho požadavků.

  • Důkladně otestujte strategie a mechanismy opakování při různých podmínkách, například při různých stavech sítě a měnících se zatíženích systému.

Strategie opakování

Toto jsou obvyklé typy strategií opakování podle intervalů mezi opakovanými pokusy:

  • Exponenciální. Zásada opakování, která provádí zadaný počet opakování, pomocí randomizovaného exponenciálního zpětného ukončení přístupu k určení intervalu mezi opakovanými pokusy. Příklad:

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

  • Přírůstkové. Strategie opakování se zadaným počtem pokusů o opakování a přírůstkovým časovým intervalem mezi opakovanými pokusy. Příklad:

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

  • LinearRetry. Zásada opakování, která provádí zadaný počet opakování pomocí zadaného pevného časového intervalu mezi opakovanými pokusy. Příklad:

    retryInterval = this.deltaBackoff;

Zpracování přechodných chyb pomocí knihovny Polly

Polly je knihovna pro programové zpracování opakovaných pokusů a strategií jističe . Projekt Polly patří organizaci .NET Foundation. Pro služby, ve kterých klient nativně nepodporuje opakování, je Polly platnou alternativou a vyhne se nutnosti psát vlastní kód opakování, což může být obtížné správně implementovat. Polly také nabízí možnost trasování chyb, takže můžete opakované pokusy protokolovat.

Další kroky

  • Odolnost připojení entity Framework