Megosztás a következőn keresztül:

Útmutató újrapróbálkozáshoz az Azure-szolgáltatásokhoz

  • Cikk

A legtöbb Azure-szolgáltatás és ügyfél-SDK tartalmaz egy újrapróbálkozási mechanizmust. Ezek azonban eltérőek lehetnek, mert minden szolgáltatásnak eltérő jellemzői és követelményei vannak, így mindegyik újrapróbálkozási mechanizmus az adott szolgáltatásra van szabva. Ez az útmutató összefoglalja a legtöbb Azure-szolgáltatás újrapróbálkozási mechanizmusának funkcióit, és információkat tartalmaz a szolgáltatás újrapróbálkozési mechanizmusának használatáról, adaptálásáról vagy kiterjesztéséről.

Általános útmutatást az átmeneti hibák kezeléséhez, valamint a szolgáltatásokat és erőforrásokat célzó kapcsolatok és műveletek újrapróbálásához az újrapróbálkozási útmutatásban talál.

A következő táblázat az útmutatóban érintett Azure-szolgáltatások újrapróbálkozási funkcióiról nyújt áttekintést.

Szolgáltatás Újrapróbálkozási képességek Szabályzatkonfiguráció Hatókör Telemetriafunkciók
Microsoft Entra ID Natív az MSAL-kódtárban Beágyazás MSAL-kódtárba Belső Egyik sem
Azure Cosmos DB Natív, a szolgáltatás része Nem konfigurálható Globális TraceSource
Data Lake Store Natív, az ügyfél része Nem konfigurálható Egyedi műveletek Egyik sem
Event Hubs Natív, az ügyfél része Szoftveres Ügyfél Egyik sem
IoT hub Natív az ügyféloldali SDK-ban Szoftveres Ügyfél Egyik sem
Azure Cache for Redis Natív, az ügyfél része Szoftveres Ügyfél TextWriter
Keresés Natív, az ügyfél része Szoftveres Ügyfél Eseménykövetés Windowshoz (ETW) vagy egyénihöz
Szolgáltatásbusz Natív, az ügyfél része Szoftveres Névtérkezelő, üzenetkezelési előállító vagy ügyfél ETW
Service Fabric Natív, az ügyfél része Szoftveres Ügyfél Egyik sem
SQL Database with ADO.NET Polly Deklaratív és szoftveres Önálló utasítások vagy kódblokkok Egyéni
SQL Database with Entity Framework Natív, az ügyfél része Szoftveres Alkalmazástartományonként globális Egyik sem
SQL Database with Entity Framework Core Natív, az ügyfél része Szoftveres Alkalmazástartományonként globális Egyik sem
Tárolás Natív, az ügyfél része Szoftveres Ügyfél- és különálló műveletek TraceSource

Feljegyzés

Az Azure beépített újrapróbálkozásának legtöbb mechanizmusa esetében jelenleg nincs mód arra, hogy eltérő újrapróbálkozési szabályzatot alkalmazzon a különböző típusú hibákra vagy kivételekre. Olyan szabályzatot kell konfigurálnia, amely az optimális átlagos teljesítményt és rendelkezésre állást biztosítja. A szabályzat finomhangolásához elemezze a naplófájlokat, hogy megállapítsa, milyen típusú átmeneti hibák szoktak történni.

Microsoft Entra ID

A Microsoft Entra ID egy átfogó identitás- és hozzáférés-kezelési felhőmegoldás, amely egyesíti az alapvető címtárszolgáltatásokat, a fejlett identitásszabályozást, a biztonságot és az alkalmazáshozzáférés-kezelést. A Microsoft Entra ID emellett egy identitáskezelési platformot is kínál a fejlesztőknek, amely központosított szabályzatok és szabályok alapján hozzáférést biztosít az alkalmazásaikhoz.

Feljegyzés

A felügyeltszolgáltatás-identitás végpontjaival kapcsolatos újrapróbálkozási útmutatásért tekintse meg az Azure-beli virtuális gépek felügyeltszolgáltatás-identitásának (MSI) használatát a jogkivonatok beszerzéséhez.

Újrapróbálkozási mechanizmus

A Microsoft Entra-azonosítóhoz beépített újrapróbálkozási mechanizmus található a Microsoft Authentication Library (MSAL) szolgáltatásban. A váratlan zárolások elkerülése érdekében azt javasoljuk, hogy a külső kódtárak és az alkalmazáskód ne próbálkozzon újra a sikertelen kapcsolatokkal, hanem engedélyezze az MSAL számára az újrapróbálkozások kezelését.

Újrapróbálkozásokra vonatkozó útmutató

A Microsoft Entra ID használatakor vegye figyelembe az alábbi irányelveket:

  • Ha lehetséges, használja az MSAL-kódtárat és a beépített támogatást az újrapróbálkozáshoz.
  • Ha a Rest API-t használja a Microsoft Entra-azonosítóhoz, próbálkozzon újra a művelettel, ha az eredménykód 429 (túl sok kérelem) vagy az 5xx tartomány hibája. Ne próbálkozzon újra más hibákért.
  • 429-re vonatkozó hibák esetén csak az Újrapróbálkozás után fejlécben megadott idő után próbálkozzon újra.
  • 5xx hibák esetén exponenciális visszatartást használjon, és az első próbálkozás legalább 5 másodperccel a válasz után történik.
  • Ne próbálkozzon újra a 429-nél és az 5xx-nél régebbi hibákon.

Következő lépések

Azure Cosmos DB

Az Azure Cosmos DB egy teljesen felügyelt többmodelles adatbázis, amely séma nélküli JSON-adatokat támogat. Teljesítménye konfigurálható és megbízható, natív JavaScript-tranzakciófeldolgozást kínál, és mivel felhőbeli felhasználásra készült, rugalmasan méretezhető.

Újrapróbálkozási mechanizmus

Az Azure Cosmos DB SDK-k automatikusan újrapróbálkoznak bizonyos hibafeltételeken, és a felhasználói alkalmazásoknak javasoljuk, hogy saját újrapróbálkozási szabályzatokkal rendelkezzenek. Tekintse meg az Azure Cosmos DB SDK-kkal rendelkező rugalmas alkalmazások tervezésének útmutatóját a hibafeltételek teljes listájához és az újrapróbálkozás időpontjához.

Telemetria

Az alkalmazás nyelvétől függően a diagnosztika és a telemetria naplóként vagy előléptetett tulajdonságként jelenik meg a műveleti válaszokban. További információ: "A diagnosztika rögzítése" szakasz az Azure Cosmos DB C# SDK-ban és az Azure Cosmos DB Java SDK-ban.

Data Lake Storage

A Data Lake Storage Gen2 teszi az Azure Storage-t az Azure-beli nagyvállalati adattavak készítésének alapjaként. A Data Lake Storage Gen2 lehetővé teszi nagy mennyiségű adat egyszerű kezelését.

Az Azure Storage Files Data Lake ügyféloldali kódtára tartalmazza azokat a képességeket, amelyek szükségesek ahhoz, hogy a fejlesztők, adattudósok és elemzők egyszerűen tárolják az adatokat bármilyen méretben, formában és sebességgel, és minden típusú feldolgozást és elemzést végezzenek különböző platformokon és nyelveken.

Újrapróbálkozási mechanizmus

A DataLakeServiceClient lehetővé teszi az Azure Data Lake-szolgáltatás erőforrásainak és fájlrendszereinek manipulálására. A tárfiók biztosítja a Data Lake szolgáltatás legfelső szintű névterét. Az ügyfél létrehozásakor megadhatja az Azure Data Lake szolgáltatáshoz (DataLakeClientOptions) való csatlakozás ügyfélkonfigurációs beállításait. A DataLakeClientOptions tartalmaz egy (az Azure.Core.ClientOptionstól örökölt) Újrapróbálkozási tulajdonságot, amely konfigurálható (RetryOptions osztály).

Telemetria

Az Azure Storage használatának és teljesítményének monitorozása fontos része a szolgáltatás üzembe helyezésének. Ilyenek például a gyakori műveletek, a nagy késésű műveletek vagy a szolgáltatásoldali szabályozást okozó műveletek.

A tárfiók összes telemetria az Azure Storage-naplókon keresztül érhető el az Azure Monitorban. Ez a funkció integrálja a tárfiókot a Log Analytics és az Event Hubs szolgáltatással, ugyanakkor lehetővé teszi a naplók archiválását egy másik tárfiókba. A metrikák és erőforrások naplóinak és a hozzájuk tartozó sémák teljes listájának megtekintéséhez tekintse meg az Azure Storage monitorozási adatreferenciáját.

Event Hubs

Az Azure Event Hubs egy rugalmas skálázású telemetriai betöltési szolgáltatás, amely események millióit gyűjti, alakítja át és tárolja.

Újrapróbálkozási mechanizmus

Az Azure Event Hubs Client Library újrapróbálkozási viselkedését az EventHubClient osztály RetryPolicy tulajdonsága vezérli. Az alapértelmezett szabályzat exponenciális visszalépéssel újrapróbálkozott, amikor az Azure Event Hubs egy átmeneti EventHubsException vagy egy OperationCanceledException. Az Event Hubs alapértelmezett újrapróbálkozási szabályzata, hogy akár 9 alkalommal is újrapróbálkozhat, akár 30 másodperces exponenciális visszatartási idővel.

Példa

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

Következő lépések

Azure Event Hubs ügyfélkódtár a .NET-hez

IoT Hub

Az Azure IoT Hub egy olyan szolgáltatás, amely eszközök csatlakoztatására, monitorozására és felügyeletére szolgál az eszközök ioT-alkalmazások fejlesztéséhez.

Újrapróbálkozási mechanizmus

Az Azure IoT-eszköz SDK képes észlelni a hálózati, protokoll- vagy alkalmazáshibákat. A hibatípus alapján az SDK ellenőrzi, hogy újra kell-e próbálkozni. Ha a hiba helyreállítható, az SDK újrapróbálkozott a konfigurált újrapróbálkozési szabályzattal.

Az alapértelmezett újrapróbálkozási szabályzat exponenciális visszalépés véletlenszerű jitterrel, de konfigurálható.

Szabályzatkonfiguráció

A szabályzatkonfiguráció nyelvenként eltérő. További információ: IoT Hub újrapróbálkozás szabályzatkonfiguráció.

Következő lépések

Azure Cache for Redis

Az Azure Cache for Redis gyors adathozzáférés és alacsony késésű gyorsítótár-szolgáltatás, amely a népszerű nyílt forráskódú Redis-gyorsítótáron alapul. Biztonságos, a Microsoft felügyeli, és az Azure bármely alkalmazásából elérhető.

Ebben az útmutatóban azt feltételezzük, hogy a StackExchange.Redis ügyfelet használja a gyorsítótár eléréséhez. A további alkalmas ügyfelek listája a Redis webhelyén tekinthető meg, ám ezeknek eltérő újrapróbálkozási mechanizmusai lehetnek.

A StackExchange.Redis-ügyfél egyetlen kapcsolaton keresztül használ multiplexálást. A javasolt felhasználás az, ha létrehozza az ügyfél egy példányát az alkalmazás indításakor, és ezt a példányt használja a gyorsítótár elérését célzó összes művelethez. Így a gyorsítótárral való kapcsolat csak egyszer jön létre, ezért az ebben a szakaszban leírt összes útmutatás ezen első kapcsolat újrapróbálkozási szabályzatára vonatkozik, nem pedig a gyorsítótárhoz hozzáférő egyes műveletekre.

Újrapróbálkozási mechanizmus

A StackExchange.Redis-ügyfél egy kapcsolatkezelő osztályt használ, amely számos beállításon keresztül van konfigurálva, például:

  • ConnectRetry. Ennyi alkalommal próbálkozik újra a gyorsítótárhoz való sikertelen kapcsolódás esetén.
  • ReconnectRetryPolicy. A használt újrapróbálkozási stratégia.
  • ConnectTimeout. A maximális várakozási idő milliszekundumban.

Szabályzatkonfiguráció

Az újrapróbálkozási szabályzat konfigurálása szoftveresen történik. Az ügyfél beállításait a gyorsítótárhoz való kapcsolódás előtt kell megadni. Ehhez létre kell hozni a ConfigurationOptions osztály egy példányát, feltölteni adatokkal a tulajdonságait, majd továbbítani azt a Connect metódusnak.

A beépített osztályok támogatják a lineáris (állandó) késleltetést, illetve az exponenciális visszatartást véletlenszerű újrapróbálkozási időközökkel. Ezenkívül létrehozhat egyéni újrapróbálkozási szabályzatot az IReconnectRetryPolicy felület implementálásával.

A következő példa exponenciális visszatartással konfigurálja az újrapróbálkozási stratégiát.

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

Egy másik lehetőség, hogy a beállításokat sztringként adja meg és továbbítja a Connect metódusnak. A ReconnectRetryPolicy tulajdonság nem állítható be így, csak kóddal.

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

Amikor a gyorsítótárhoz csatlakozik, közvetlenül is megadhat beállításokat.

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

További információért tekintse meg a Stack Exchange Redis konfigurálását a StackExchange.Redis dokumentációjában.

A következő táblázatban a beépített újrapróbálkozási szabályzat alapértelmezett beállításai láthatók.

Környezet Beállítás Alapértelmezett érték
(v 1.2.2)		 Jelentés
ConfigurationOptions ConnectRetry

ConnectTimeout

SyncTimeout

ReconnectRetryPolicy		 3

Legfeljebb 5000 ms, plusz SyncTimeout
1000

LinearRetry 5000 ms		 Ennyi alkalommal kell megismételni a csatlakozási kísérletet az első csatlakozási művelet során.
A csatlakozási műveletek időtúllépési értéke (ms). Nem az újrapróbálkozás kísérletek közötti késleltetést jelzi.
A szinkron műveletek számára biztosított idő (ms).

Újrapróbálkozás 5000 ms időközönként.

Feljegyzés

A szinkron műveletek esetében a SyncTimeout hozzájárulhat a végpontok közötti késéshez, de a túl alacsony érték gyakori időtúllépéseket eredményezhet. További információ: Az Azure Cache for Redis hibaelhárítása. Általában kerülje a szinkron műveletek használatát, és alkalmazzon inkább aszinkron műveleteket. További információ: Folyamatok és multiplexerek.

Újrapróbálkozásokra vonatkozó útmutató

Az Azure Cache for Redis használatakor vegye figyelembe az alábbi irányelveket:

  • A StackExchange Redis ügyfél kezeli a saját újrapróbálkozásait, de csak amikor az alkalmazás első indításakor próbál kapcsolódni a gyorsítótárhoz. Konfigurálhatja a kapcsolat időtúllépését, az újrapróbálkozási kísérletek számát és az újrapróbálkozások közötti időt a kapcsolat létrehozásához, de az újrapróbálkozási szabályzat nem vonatkozik a gyorsítótáron végzett műveletekre.
  • Nagy számú újrapróbálkozási kísérlet helyett érdemes lehet inkább az eredeti adatforráshoz csatlakozni.

Telemetria

TextWriter használatával adatokat gyűjthet a kapcsolatokról (más műveletekről azonban nem).

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

Az alábbi példa azt mutatja be, hogy ez milyen kimenetet eredményez.

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éldák

A következő mintakód állandó (lineáris) késleltetést állít be az újrapróbálkozások között a StackExchange.Redis ügyfél inicializálásakor. Ez a példa azt mutatja be, hogyan állítható be a konfiguráció egy ConfigurationOptions-példánnyal.

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

A következő példa sztringként adja meg a beállításokat, és így határozza meg a konfigurációt. A kapcsolat időtúllépése a leghosszabb idő, amennyit a kapcsolat a gyorsítótárra várhat, nem pedig az újrapróbálkozási kísérletek közötti időköz. A ReconnectRetryPolicy tulajdonság csak kóddal állítható be.

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

További példákért tekintse meg a projekt webhelyének a konfigurációval foglalkozó szakaszát.

Következő lépések

Az Azure Search hatékony és kifinomult keresési lehetőségekkel egészíthet ki egy webhelyet vagy alkalmazást, gyorsan és könnyen pontosítja a keresési eredményeket, továbbá részletes és finomhangolt rangsorolási modelleket képes létrehozni.

Újrapróbálkozási mechanizmus

A .NET-hez készült Azure SDK tartalmaz egy Azure.Search.Documents ügyfélkódtárat az Azure SDK csapatából, amely funkcionálisan egyenértékű az előző ügyfélkódtár, a Microsoft.Azure.Search szolgáltatáséval.

A Microsoft.Azure.Search újrapróbálkozási viselkedését a SetRetryPolicy metódus szabályozza a SearchServiceClient és a SearchIndexClient osztályokon. Az alapértelmezett szabályzat exponenciális visszatartással végzi el az újrapróbálkozást, ha az Azure Search 5xx-es vagy 408-as (Kérés időtúllépése) választ ad vissza.

Az Azure.Search.Documents újrapróbálkozási viselkedését a SearchClientOptions (a SearchClient-konstruktor része) szabályozza a Retry tulajdonságban, amely az Azure.Core.RetryOptions osztályhoz tartozik (ahol minden konfiguráció elérhető).

Telemetria

Nyomkövetés ETW-vel vagy egyéni nyomkövetési szolgáltató regisztrálásával. További információt az AutoRest dokumentációjában találhat.

Service Bus

A Service Bus egy felhőalapú üzenetkezelési platform, amely skálázható és rugalmas módon biztosít lazán kapcsolódó üzenetváltásokat az alkalmazások összetevői számára, legyen szó felhőalapú vagy helyszíni megoldásról.

Újrapróbálkozási mechanizmus

A névtér és néhány konfigurációs részlet attól függ, hogy melyik Service Bus-ügyfél SDK-csomagot használja:

Csomag Leírás Névtér
Azure.Messaging.ServiceBus Azure Service Bus ügyfélkódtár a .NET-hez Azure.Messaging.ServiceBus
WindowsAzure.ServiceBus Ez a csomag a régebbi Service Bus-ügyfélkódtár. A .NET-keretrendszer 4.5.2-t igényel. Microsoft.Azure.ServiceBus

Újrapróbálkozásokra vonatkozó útmutató

A ServiceBusRetryOptions tulajdonság az objektum újrapróbálkozési ServiceBusClient beállításait adja meg:

Beállítás Alapértelmezett érték Értelmezés
CustomRetryPolicy Az egyéni beállításértékek helyett használandó egyéni újrapróbálkozési szabályzat.
Késés 0,8 másodperc A rögzített megközelítés újrapróbálkozási kísérletei közötti késés, vagy az a késés, amelyre a visszalépésen alapuló megközelítés számításait alapozza.
MaxDelay 60 másodperc Az újrapróbálkozási kísérletek közötti legnagyobb megengedett késleltetés.
MaxRetries 3 Az újrapróbálkozások maximális száma, mielőtt a társított művelet sikertelennek tekintené.
Mód Exponenciális Az újrapróbálkozási késések kiszámításának módszere.
TryTimeout 60 másodperc Az egyetlen kísérlet befejezésére váró maximális időtartam, függetlenül attól, hogy a kezdeti kísérlet vagy az újrapróbálkozás.

Állítsa be a Mode tulajdonságot a ServiceBusRetryMode konfigurálásához az alábbi értékek bármelyikével:

Tulajdonság Érték Leírás
Exponenciális 0 Az újrapróbálkozási kísérletek egy visszalépési stratégia alapján késnek, ahol minden kísérlet növeli az újrapróbálkozás előtt várakozó időtartamot.
Rögzített méretű lemez 0 Az újrapróbálkozási kísérletek rögzített időközönként történnek; minden késleltetés egy konzisztens időtartam.

Példa:

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

A Service Bus ugyanazokat a monitorozási adatokat gyűjti, mint más Azure-erőforrások. Az Azure Service Bust az Azure Monitor használatával figyelheti.

A telemetriai adatok Service Bus .NET-ügyfélkódtárakkal való küldésére is többféle lehetőség közül választhat.

Példa

Az alábbi példakód bemutatja, hogyan használhatja a csomagot:Azure.Messaging.ServiceBus

  • Állítsa be az újrapróbálkozési szabályzatot egy ServiceBusClient új ServiceBusClientOptionsfelhasználóhoz.
  • Hozzon létre egy új üzenetet egy új példányával ServiceBusMessage.
  • Küldjön üzenetet a Service Busnak a ServiceBusSender.SendMessageAsync(message) metódus használatával.
  • Fogadás az ServiceBusReceiverobjektumként ServiceBusReceivedMessage ábrázolt elemet használva.
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);

Következő lépések

Service Fabric

A megbízható szolgáltatások Service Fabric-fürtön belüli elosztásával a cikkben tárgyalt legtöbb átmeneti hiba elkerülhető. Azonban így is előfordulhatnak átmeneti hibák. Előfordulhat például, hogy a kérés érkezésekor az elnevezési szolgáltatás egy útválasztási változtatást végez, ami kivételt eredményez. Ugyanez a kérés 100 milliszekundummal később talán sikeres lett volna.

A Service Fabric az ehhez hasonló átmeneti hibák belső kezelését elvégzi. A szolgáltatás beállítása közben konfigurálhat egyes beállításokat az OperationRetrySettings osztállyal. Az alábbi kód erre mutat egy példát. A legtöbb esetben ez nem szükséges, és az alapértelmezett beállítások rendben lesznek.

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

Következő lépések

SQL Database ADO.NET használatával

Az SQL Database egy üzemeltetett SQL Database, amely számos méretben és standard (megosztott) és prémium (nem megosztott) szolgáltatásként érhető el.

Újrapróbálkozási mechanizmus

Az SQL Database nem tartalmaz beépített támogatást az újrapróbálkozásokhoz, ha az ADO.NET használatával érik el. Ugyanakkor a kérések válaszkódjából megállapítható, hogy a kérés miért hiúsult meg. További információt az SQL Database szabályozásáról az Azure SQL Database erőforrás-korlátait ismertető szakaszban talál. A kapcsolódó hibakódok listáját az SQL Database ügyfélalkalmazásaiban felmerülő SQL-hibakódokat ismertető szakaszban találja.

A Polly kódtárt alkalmazva implementálhatja az újrapróbálkozást az SQL Database-ben. További információ: Átmeneti hibakezelés a Pollyval.

Újrapróbálkozásokra vonatkozó útmutató

Ügyeljen a következőkre, amikor az ADO.NET használatával éri el az SQL Database-t:

  • Válassza a megfelelő szolgáltatástípust (megosztott vagy prémium). A megosztott példány esetében a szokottnál hosszabb csatlakozási késések fordulhatnak elő, valamint a kérések számának korlátozására lehet szükség, mivel a megosztott kiszolgálót más bérlők is használják. Ha kiszámíthatóbb teljesítményre és megbízhatóan alacsony késésű műveletekre van szükség, mindenképpen a prémium szolgáltatást érdemes választani.
  • Gondoskodjon arról, hogy az újrapróbálkozás a megfelelő szinten vagy hatókörrel legyen végrehajtva, amivel elkerülheti, hogy a nem idempotens műveletek miatt inkonzisztencia keletkezzen az adatokban. Ideális esetben minden műveletnek idempotensnek kellene lennie, hogy inkonzisztencia veszélye nélkül lehessen ismételni azokat. Ha nem ez a helyzet, az újrapróbálkozási műveletet olyan szinten vagy hatókörben kell végrehajtani, amely lehetővé teszi az összes kapcsolódó módosítás visszavonását, ha egy művelet meghiúsul; például egy tranzakciós hatókörön belülről. További információt a Cloud Service Fundamentals adatelérési réteg átmeneti hibák kezelésével foglalkozó részében talál.
  • Az Azure SQL Database-hez nem ajánlott rögzített időközi stratégia használata, kivéve azokat az interaktív forgatókönyveket, amelyekben csak néhány újrapróbálkozás van rövid időközönként. Ehelyett fontolja meg exponenciális visszalépési stratégia használatát a legtöbb forgatókönyv esetében.
  • A kapcsolatok definiálásakor válasszon megfelelő értéket a kapcsolatok és a parancsok időtúllépéséhez. A túl alacsony időtúllépési érték miatt a kapcsolatok idő előtt szakadhatnak meg, ha az adatbázis leterhelt. A túl magas időtúllépési érték akadályozhatja az újrapróbálkozási logika megfelelő működését, mivel túl sokáig fog várni, mielőtt észlelné a sikertelen csatlakozást. Az időtúllépés értéke a végpontok közötti késés egyik összetevője; a rendszer hatékonyan hozzáadja az újrapróbálkozási szabályzatban megadott újrapróbálkozási késleltetéshez minden újrapróbálkozási kísérlethez.
  • Néhány újrapróbálkozás után zárja be a kapcsolatot, még akkor is, ha exponenciális visszalépési logikát használ, és próbálkozzon újra a művelettel egy új kapcsolaton. Ha ugyanazzal a művelettel többször próbálkozik újra ugyanazon a kapcsolaton keresztül, az önmagában is csatlakozási problémákat okozhat. Erre a technikára egy példát a Cloud Service Fundamentals adatelérési réteg átmeneti hibák kezelésével foglalkozó részében találhat.
  • Ha a kapcsolatkészletezés használatban van (az alapértelmezett), akkor a kapcsolat bezárása és újbóli megnyitása után is előfordulhat, hogy ugyanazt a kapcsolatot választja ki a készletből. Ha igen, a megoldás egyik módszere az SqlConnection osztály ClearPool metódusának meghívása, hogy a kapcsolat ne legyen újrafelhasználható. Ezt azonban csak abban az esetben javasoljuk, ha számos csatlakozási kísérlet meghiúsult, és csak akkor, ha az átmeneti hibák, például SQL-időtúllépések (-2-es hibakód) adott osztálya hibás kapcsolatokhoz kötődik.
  • Amennyiben az adatelérési kód TransactionScope-példányként kezdeményezett tranzakciókat alkalmaz, az újrapróbálkozási logikának újra meg kell nyitnia a kapcsolatot, és új tranzakció-hatókört kell kezdeményeznie. Ezért az újrapróbálható kódblokknak a tranzakció teljes hatókörét le kell fedne.

A következő kezdőbeállításokat javasoljuk az újrapróbálkozási műveletekhez. Ezek a beállítások általános célúak, és figyelnie kell a műveleteket, és finomhangolnia kell az értékeket a saját forgatókönyvének megfelelően.

Környezet Minta cél E2E
maximális késés		 Újrapróbálkozási stratégia Beállítások Értékek Működési elv
Interaktív, felhasználói felület
vagy előtér		 2 másodperc FixedInterval Ismétlések száma
Újrapróbálkozási időköz
Első gyors újrapróbálkozás		 3
500 ms
true		 1. kísérlet – 0 mp. késleltetés
2. kísérlet – 500 ms késleltetés
3. kísérlet – 500 ms késleltetés
Háttér
vagy kötegelt		 30 másodperc ExponentialBackoff Ismétlések száma
Visszatartás (min.)
Visszatartás (max.)
Visszatartás (változás)
Első gyors újrapróbálkozás		 5
0 másodperc
60 másodperc
2 másodperc
false		 1. kísérlet – 0 mp. késleltetés
2. kísérlet – kb. 2 mp. késleltetés
3. kísérlet – kb. 6 mp. késleltetés
4. kísérlet – kb. 14 mp. késleltetés
5. kísérlet – kb. 30 mp. késleltetés

Feljegyzés

A végpontok közötti késés célértéke az alapértelmezett időtúllépési érték használatát feltételezi a szolgáltatáskapcsolatokhoz. Ha magasabb értéket ad meg a kapcsolatok időtúllépésére, a végpontok közötti késés minden újrapróbálkozási kísérlet esetében ennyivel lesz meghosszabbítva.

Példák

Ebben a szakaszban azt mutatjuk be, hogy miként használhatja a Pollyt az Azure SQL Database elérésére a Policy osztályban konfigurált újrapróbálkozási szabályzatok segítségével.

A következő programkód bemutatja, hogyan bővítheti az SqlCommand osztályt, ha az exponenciális visszatartással hívja meg az ExecuteAsync metódust.

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

Ezt az aszinkron bővítési metódust a következőképpen lehet használni.

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

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

Következő lépések

SQL Database az Entity Framework 6 használatával

Az SQL Database egy üzemeltetett SQL Database, amely számos méretben és standard (megosztott) és prémium (nem megosztott) szolgáltatásként érhető el. Az Entity Framework egy objektumrelációs leképező .NET-fejlesztők számára, amellyel tartományspecifikus objektumokat használva lehet relációs adatokkal dolgozni. Szükségtelenné teszi az adatelérési kód használatát, amelyet egyébként a fejlesztőknek kell megírniuk.

Újrapróbálkozási mechanizmus

Az újrapróbálkozási támogatás akkor érhető el, ha az SQL Database-hez az Entity Framework 6.0-s vagy újabb verziójával fér hozzá egy Kapcsolat rugalmassága/ újrapróbálkozási logika nevű mechanizmussal. Az újrapróbálkozási mechanizmus fő funkciói a következők:

  • Az elsődleges absztrakció az IDbExecutionStrategy felület. Ez a felület:
    • Szinkron és aszinkron végrehajtási metódusokat definiál.
    • Definiálja azokat az osztályokat, amelyek felhasználhatók közvetlenül, illetve konfigurálhatók alapértelmezett stratégiaként egy adatbázis-környezetben, leképezhetők egy szolgáltatónévre, vagy pedig leképezhetők egy szolgáltatónévre vagy kiszolgálónévre. Ha egy környezethez konfigurálják, az újrapróbálkozások az egyes adatbázis-műveletek szintjén történnek, amelyekből több is lehet egy adott környezeti művelet esetében.
    • Definiálja, hogy a sikertelen csatlakozást mikor kövesse újrapróbálkozás, és hogyan.
  • Az IDbExecutionStrategy felület számos beépített implementációját tartalmazza:
    • Alapértelmezett: nincs újrapróbálkozás.
    • Az SQL Database alapértelmezett értéke (automatikus): nincs újrapróbálkozás, de figyelembe véve a kivételeket, és javaslatot ad az SQL Database-stratégia használatára.
    • Az SQL Database alapértelmezett értéke: exponenciális (az alaposztálytól örökölt) és az SQL Database észlelési logikája.
  • Véletlenszerűsítést tartalmazó exponenciális visszatartási stratégiát implementál.
  • A beépített újrapróbálkozési osztályok állapotalapúak, és nem szálbiztosak. Ugyanakkor az aktuális művelet befejezése után újra felhasználhatók.
  • Amennyiben az újrapróbálkozások száma meghaladja a megadott értéket, a szolgáltatás új kivételbe burkolja az eredményeket. Nem buborékozza fel az aktuális kivételt.

Szabályzatkonfiguráció

Az újrapróbálkozás akkor támogatott, ha az SQL Database-t az Entity Framework 6.0-s vagy újabb verziójával érik el. Az újrapróbálkozási szabályzatok konfigurálása szoftveresen történik. A konfiguráció nem módosítható műveletenként.

Ha egy környezetfüggő stratégiát tesz alapértelmezetté, megad egy függvényt, amely igény szerint hoz létre egy új stratégiát. A következő kód azt mutatja be, hogyan hozható létre egy újrapróbálkozási konfigurációs osztályt, amely kibővíti a DbConfiguration alaposztályt.

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

Az alkalmazás indításakor, a DbConfiguration-példány SetConfiguration metódusával teheti az alapértelmezett újrapróbálkozási stratégiává minden művelet számára. Alapértelmezés szerint az EF automatikusan észleli és használatba veszi a konfigurációs osztályt.

DbConfiguration.SetConfiguration(new BloggingContextConfiguration());

Ha meg kíván adni egy újrapróbálkozási konfigurációs osztályt a környezethez, lássa el a környezeti osztályt egy DbConfigurationType attribútummal. Amennyiben csak egy konfigurációs osztálya van, az EF azt fogja használni, nem szükséges külön jeleznie ezt.

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

Ha eltérő újrapróbálkozási stratégiára van szüksége adott műveletek esetében, vagy le kívánja tiltani az újrapróbálkozásokat egyes műveleteknél, létrehozhat egy konfigurációs osztályt, amely lehetővé teszi stratégiák felfüggesztését vagy cseréjét egy jelző a CallContext osztályban történő elhelyezésével. A konfigurációs osztály ezt a jelzőt használva vált stratégiát vagy tiltja le a felhasználó által megadott stratégiát, majd az alapértelmezett stratégiát használja. További információt a végrehajtási stratégia felfüggesztése (EF6) című témakörben talál.

Bizonyos műveletek esetében egy másik lehetőség adott újrapróbálkozási stratégia használatára, ha létrehozza a kívánt stratégiaosztály egy példányát, és paramétereket használva ellátja a kívánt beállításokkal. Ezután meghívja annak ExecuteAsync metódusát.

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

A DbConfiguration osztály használatának legegyszerűbb módja, ha megkeresi ugyanazt a szerelvényt, amely a DbContext osztályban szerepel. Ez azonban nem megfelelő, ha ugyanaz a környezet szükséges különböző forgatókönyvekben, például különböző interaktív és háttérbeli újrapróbálkozások esetén. Ha a különböző környezetek különálló alkalmazástartományokban futnak, igénybe veheti a konfigurációs osztályok a konfigurációs fájlban történő megadásának beépített lehetőségét, illetve beállíthatja azt közvetlenül is a kódban. Ha a különböző környezeteknek ugyanabban az alkalmazástartományban kell futniuk, egyéni megoldásra lesz szükség.

További információ: Kódalapú konfiguráció (EF6 tovább).

A következő táblázatban a beépített újrapróbálkozási szabályzat alapértelmezett beállításai láthatók az EF6 használatakor.

Beállítás Alapértelmezett érték Értelmezés
Szabályzat Exponenciális Exponenciális visszatartás.
MaxRetryCount 5 Az újrapróbálkozások maximális száma.
MaxDelay 30 másodperc Az újrapróbálkozások közötti maximális késleltetés. Ez az érték nem befolyásolja a késések sorozatának kiszámítását. Csak a felső határt adja meg.
DefaultCoefficient 1 másodperc Az exponenciális visszatartás számításának együtthatója. Ez az érték nem módosítható.
DefaultRandomFactor 1,1 A véletlenszerű késleltetés bejegyzésekhez való hozzáadására szolgáló szorzó. Ez az érték nem módosítható.
DefaultExponentialBase 2 A következő késleltetés kiszámítására szolgáló szorzó. Ez az érték nem módosítható.

Újrapróbálkozásokra vonatkozó útmutató

Ügyeljen a következőkre, amikor az EF6 használatával éri el az SQL Database-t:

  • Válassza a megfelelő szolgáltatástípust (megosztott vagy prémium). A megosztott példány esetében a szokottnál hosszabb csatlakozási késések fordulhatnak elő, valamint a kérések számának korlátozására lehet szükség, mivel a megosztott kiszolgálót más bérlők is használják. Ha kiszámítható teljesítményre és megbízhatóan alacsony késésű műveletekre van szükség, mindenképpen a prémium szolgáltatást érdemes választani.

  • Az Azure SQL Database-hez nem ajánlott rögzített időközi stratégiát használni. Használjon inkább egy exponenciális visszatartási stratégiát, mivel a szolgáltatás túlterhelődhet, és a hosszabb késleltetés több időt ad a helyreállításra.

  • A kapcsolatok definiálásakor válasszon megfelelő értéket a kapcsolatok és a parancsok időtúllépéséhez. Az időtúllépés ideális értékét saját üzleti logikájának felépítése és tesztek alapján állapíthatja meg. A későbbiekben szükség lehet az érték módosítására, ahogy változik az adatmennyiség, vagy változnak az üzleti folyamatok. A túl alacsony időtúllépési érték miatt a kapcsolatok idő előtt szakadhatnak meg, ha az adatbázis leterhelt. A túl magas időtúllépési érték akadályozhatja az újrapróbálkozási logika megfelelő működését, mivel túl sokáig fog várni, mielőtt észlelné a sikertelen csatlakozást. Az időtúllépés értéke a végpontok közötti késés egyik összetevője, bár nem lehet könnyen meghatározni, hogy hány parancsot hajt végre a környezet mentésekor. Az alapértelmezett időtúllépést a DbContext példány CommandTimeout tulajdonságában adhatja meg.

  • Az Entity Framework támogatja a konfigurációs fájlokban definiált újrapróbálkozási konfigurációk használatát. Ugyanakkor a minél nagyobb rugalmasság érdekében azt javasoljuk, hogy a konfigurációt szoftveresen hozza létre az alkalmazásban. Az újrapróbálkozási szabályzatok konkrét paraméterei – például az újrapróbálkozások száma és az újrapróbálkozási időközök – a szolgáltatás konfigurációs fájljában tárolhatók, és a futtatás során felhasználhatók a megfelelő szabályzatok létrehozására. Így a beállítások az alkalmazás újraindítása nélkül módosíthatók.

A következő kezdőbeállításokat javasoljuk az újrapróbálkozási műveletekhez. Nem adhatja meg az újrapróbálkozási kísérletek közötti késleltetést (ez rögzített és exponenciális sorozatként jön létre). Ha nem hoz létre egyéni újrapróbálkozási stratégiát, csak a maximális értékeket adhatja meg, az itt látható módon. Ezek a beállítások általános célúak, és figyelnie kell a műveleteket, és finomhangolnia kell az értékeket a saját forgatókönyvének megfelelően.

Környezet Minta cél E2E
maximális késés		 Újrapróbálkozási szabályzat Beállítások Értékek Működési elv
Interaktív, felhasználói felület
vagy előtér		 2 másodperc Exponenciális MaxRetryCount
MaxDelay		 3
750 ms		 1. kísérlet – 0 mp. késleltetés
2. kísérlet – 750 ms késleltetés
3. kísérlet – 750 ms késleltetés
Háttér
vagy kötegelt		 30 másodperc Exponenciális MaxRetryCount
MaxDelay		 5
12 másodperc		 1. kísérlet – 0 mp. késleltetés
2. kísérlet – kb. 1 mp. késleltetés
3. kísérlet – kb. 3 mp. késleltetés
4. kísérlet – kb. 7 mp. késleltetés
5. kísérlet – 12 mp. késleltetés

Feljegyzés

A végpontok közötti késés célértéke az alapértelmezett időtúllépési érték használatát feltételezi a szolgáltatáskapcsolatokhoz. Ha magasabb értéket ad meg a kapcsolatok időtúllépésére, a végpontok közötti késés minden újrapróbálkozási kísérlet esetében ennyivel lesz meghosszabbítva.

Példák

A következő mintakód egy egyszerű adatelérési megoldást definiál, amely az Entity Frameworköt használja. Egy adott újrapróbálkozási stratégiát állít be a BlogConfiguration osztály egy példányának definiálásával, amely a DbConfiguration osztályt bővíti ki.

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

Az Entity Framework újrapróbálkozási mechanizmusának használatára további példákat talál a Kapcsolat rugalmassága/újrapróbálkozási logikájában.

SQL Database az Entity Framework Core használatával

Az Entity Framework Core egy objektumrelációs leképező .NET Core-fejlesztők számára, amellyel tartományspecifikus objektumokat használva lehet adatokkal dolgozni. Szükségtelenné teszi az adatelérési kód használatát, amelyet egyébként a fejlesztőknek kell megírniuk. Az Entity Framework e verzióját az alapoktól építettük újra, ezért nem örökli meg automatikusan az EF6.x összes funkcióját.

Újrapróbálkozási mechanizmus

Az újrapróbálkozási támogatás akkor érhető el, ha az SQL Database-hez az Entity Framework Core használatával egy kapcsolati rugalmasság nevű mechanizmuson keresztül fér hozzá. A kapcsolat rugalmassága először az EF Core 1.1.0-ban vált elérhetővé.

Az elsődleges absztrakció az IExecutionStrategy felület. Az SQL Server végrehajtási stratégiája, beleértve az Azure SQL-t is, tisztában van az újrapróbálkozható kivételtípusokkal, és ésszerű alapértelmezett értékekkel rendelkezik a maximális újrapróbálkozásokhoz, az újrapróbálkozások közötti késleltetéshez stb.

Példák

A következő kód lehetővé teszi az automatikus újrapróbálkozást a DbContext objektum konfigurálásakor, ami egy munkamenetet jelöl az adatbázisban.

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

A következő kód bemutatja, egy végrehajtási stratégia alkalmazásával hogyan hajtható végre egy tranzakció automatikus újrapróbálkozással. A tranzakciót egy delegált definiálja. Átmeneti hiba előfordulásakor a végrehajtási stratégia ismét meghívja a delegáltat.

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

Az Azure Storage-szolgáltatások közé tartoznak a blobtárolók, a fájlok és a tárolási üzenetsorok.

Blobok, üzenetsorok és fájlok

A ClientOptions osztály az összes ügyfélbeállítás-típus alaptípusa, és különböző gyakori ügyfélbeállításokat tesz elérhetővé, például Diagnosztika, Újrapróbálkozás, Átvitel. Az Azure Queuehoz, Blobhoz és File Storage-hoz való csatlakozás ügyfélkonfigurációs beállításainak megadásához a megfelelő származtatott típust kell használnia. A következő példában a QueueClientOptions osztályt (a ClientOptionsból származtatva) konfigurálja az ügyfelet az Azure Queue Service-hez való csatlakozáshoz. Az Újrapróbálkozási tulajdonság az újrapróbálkozási kísérletek módjának és a sikertelen próbálkozások újrapróbálkozásának befolyásolásához megadható beállítások halmaza.

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

Táblatámogatás

Feljegyzés

A WindowsAzure.Storage Nuget-csomag és a Microsoft.Azure.Cosmos.Table Nuget-csomag elavult. Az Azure-tábla támogatásáról lásd: Azure.Data.Tables Nuget Package

Újrapróbálkozási mechanizmus

Az ügyfélkódtár az Azure Core-kódtáron alapul, amely egy olyan kódtár, amely horizontális szolgáltatásokat biztosít más ügyfélkódtárak számára.

Számos oka lehet annak, ha egy ügyfélalkalmazás hálózati kérést próbál elküldeni egy szolgáltatásnak. Ilyenek például az időtúllépés, a hálózati infrastruktúra hibái, a kérést a szabályozás/foglaltság miatt elutasító szolgáltatás, a szolgáltatáspéldány a szolgáltatás leskálázása miatt leáll, a szolgáltatáspéldányt lecserélik egy másik verzióra, a szolgáltatás nem kezelt kivétel miatt összeomlik stb. Egy beépített újrapróbálkozási mechanizmussal (az alapértelmezett konfigurációval, amelyet a fogyasztó felülbírálhat), az SDK-k és a fogyasztó alkalmazása ellenállóbbá válik az ilyen típusú hibákkal szemben. Vegye figyelembe, hogy egyes szolgáltatások valós pénzt számítanak fel az egyes kérésekért, ezért a fogyasztóknak teljes mértékben le kell tiltaniuk az újrapróbálkozásokat, ha a rugalmasság helyett pénzt szeretnének megtakarítani.

Szabályzatkonfiguráció

Az újrapróbálkozási szabályzatok konfigurálása szoftveresen történik. A konfiguráció a RetryOption osztályon alapul. A TableClientOptions attribútuma a ClientOptionstól öröklődik

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

Az alábbi táblázatok a beépített újrapróbálkozési szabályzatok lehetőségeit mutatják be.

RetryOption

Beállítás Jelentés
Késés A rögzített megközelítés újrapróbálkozási kísérletei közötti késés, vagy az a késés, amelyre a visszalépésen alapuló megközelítés számításait alapozza. Ha a szolgáltatás újrapróbálkozási válaszfejlécet biztosít, a következő újrapróbálkozást a fejléc értéke által megadott időtartam késlelteti.
MaxDelay Az újrapróbálkozási kísérletek közötti legnagyobb megengedett késleltetés, ha a szolgáltatás nem ad meg újrapróbálkozási válaszfejlécet. Ha a szolgáltatás újrapróbálkozási válaszfejlécet biztosít, a következő újrapróbálkozást a fejléc értéke által megadott időtartam késlelteti.
Mód Az újrapróbálkozási késések kiszámításának módszere.
NetworkTimeout Az egyes hálózati műveletekre alkalmazott időtúllépés.

RetryMode

Beállítás Jelentés
Exponenciális Az újrapróbálkozási kísérletek egy visszalépési stratégia alapján késnek, ahol minden kísérlet növeli az újrapróbálkozás előtt várakozó időtartamot.
MaxDelay Az újrapróbálkozási kísérletek rögzített időközönként történnek; minden késleltetés egy konzisztens időtartam.

Telemetria

A naplók megtekintésének legegyszerűbb módja a konzolnaplózás engedélyezése. Azure SDK-naplófigyelő létrehozásához, amely üzeneteket ad ki a konzolra az AzureEventSourceListener.CreateConsoleLogger metódus használatával.

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

Példák

Ha a következő kód példáját a táremulátor leállásával hajtja végre, az lehetővé teszi számunkra az újrapróbálkozással kapcsolatos információk megtekintését a konzolon.

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

Általános REST- és újrapróbálkozási irányelvek

Az Azure- vagy külső szolgáltatások elérésekor vegye figyelembe a következőket:

  • Alkalmazzon rendszerszintű megközelítést az újrapróbálkozások kezelésére, például egy újrafelhasználható kód formájában, hogy minden ügyfél és megoldás esetében ugyanaz a módszertan érvényesüljön.

  • Érdemes lehet újrapróbálkozési keretrendszert (például Pollyt ) használni az újrapróbálkozések kezeléséhez, ha a célszolgáltatás vagy ügyfél nem rendelkezik beépített újrapróbálkozásos mechanizmussal. Így konzisztens újrapróbálkozási viselkedés valósítható meg, és megfelelő alapértelmezett újrapróbálkozási stratégiát tehet elérhetővé a célszolgáltatás számára. Előfordulhat azonban, hogy egyéni újrapróbálkozási kódot kell létrehoznia olyan szolgáltatásokhoz, amelyek nem megfelelő viselkedéssel rendelkeznek, és nem hivatkoznak kivételekre az átmeneti hibák jelzéséhez, vagy ha újrapróbálkozási válasz válasz használatával szeretné kezelni az újrapróbálkozási viselkedést.

  • Az átmeneti hibák észlelési logikája a REST-hívások végrehajtására ténylegesen használt ügyfél-API-tól függ. Egyes ügyfelek, például az újabb HttpClient-osztály , nem fognak kivételeket kivenni a sikertelen HTTP-állapotkóddal rendelkező befejezett kérések alól.

  • A szolgáltatás által visszaadott HTTP-állapotkód segíthet megállapítani, hogy a hiba átmeneti jellegű-e. Lehet, hogy az állapotkód vagy az azzal egyenértékű kivételtípus megismeréséhez meg kell vizsgálnia az ügyfél vagy az újrapróbálkozási keretrendszer által előállított kivételeket. A következő HTTP-kódok általában azt jelzik, hogy érdemes újrapróbálkozni:

    • 408 Kérés időtúllépése
    • 429 – Túl sok kérelem
    • 500 Belső kiszolgálóhiba
    • 502 Hibás átjáró
    • 503 A szolgáltatás nem érhető el
    • 504 Időtúllépés az átjárón

  • Amennyiben kivételekre épül az újrapróbálkozási logikája, a következők általában a csatlakozást meghiúsító átmeneti hibát jeleznek:

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

  • Amennyiben egy szolgáltatás állapota „Nem érhető el”, előfordulhat, hogy a szolgáltatás a megfelelő késleltetést jelzi, mielőtt újrapróbálkozna a Retry-After válaszfejlécben vagy egy másik egyéni fejlécben. A szolgáltatások további információkat küldhetnek egyéni fejlécként, vagy a válasz tartalmába beágyazva.

  • Ne próbálkozzon újra az ügyfélhibákat jelző állapotkódokkal (a 4xx tartomány hibáival), kivéve a 408 kérelem időtúllépését és a 429 túl sok kérést.

  • Tesztelje le alaposan az újrapróbálkozási stratégiáit és mechanizmusait különböző feltételek mellett, például különböző hálózati állapotok és rendszerterhelések esetén.

Újrapróbálkozási stratégiák

A következők az újrapróbálkozási stratégiák időközeinek jellemző típusai:

  • Exponenciális. Egy újrapróbálkozási szabályzat, amely meghatározott számú újrapróbálkozási eljárást hajt végre véletlenszerű exponenciális visszalépési módszerrel az újrapróbálkozások közötti intervallum meghatározásához. Példa:

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

  • Növekményes. Újrapróbálkozási stratégia megadott számú újrapróbálkozási kísérlettel és az újrapróbálkozások közötti növekményes időintervallummal. Példa:

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

  • LinearRetry. Egy újrapróbálkozási szabályzat, amely meghatározott számú újrapróbálkozási műveletet hajt végre az újrapróbálkozások között megadott rögzített időintervallum használatával. Példa:

    retryInterval = this.deltaBackoff;

Átmeneti hibák kezelése a Polly használatával

A Polly egy kódtár, amely programozott módon kezeli az újrapróbálkozásokat és a megszakító stratégiákat. A Polly projekt a .NET Foundation keretében érhető el. Az olyan szolgáltatások esetében, ahol az ügyfél natív módon nem támogatja az újrapróbálkozásokat, a Polly egy érvényes alternatíva, és elkerüli az egyéni újrapróbálkozások kódjának írását, amelyet nehéz lehet helyesen implementálni. A Polly ezenkívül módot ad a hibák nyomon követésére, így naplózhatóvá teszi az újrapróbálkozásokat.

Következő lépések