Sdílet prostřednictvím

Doporučení pro řešení přechodných poruch

Tento průvodce popisuje doporučení pro řešení přechodných poruch ve vašich cloudových aplikacích. Všechny aplikace, které komunikují se vzdálenými službami a prostředky, musí být citlivé na přechodné poruchy. To platí zejména pro aplikace, které běží v cloudu, kde se kvůli povaze prostředí a připojení přes internet pravděpodobně setkáte s tímto typem závady častěji. Přechodné poruchy zahrnují okamžitou ztrátu síťového připojení ke komponentám a službám, dočasnou nedostupnost služby a časové limity, ke kterým dochází, když je služba zaneprázdněna. Tyto chyby se často opravují samy, takže pokud se akce opakuje po vhodné prodlevě, je pravděpodobné, že uspěje.

Tento článek obsahuje obecné pokyny pro zpracování přechodných chyb. Informace o implementaci opakování v kódu aplikace pro zpracování přechodných chyb najdete v modelu opakování a při používání služeb Azure najdete pokyny k opakování pro služby Azure.

Terminologie

Než začnete implementovat zpracování přechodných chyb, seznamte se s těmito klíčovými termíny.

Term definice
Vzor návrhu jističe Vzor návrhu, který brání opakovaným pokusům o operaci, která pravděpodobně selže. Po prahové hodnotě selhání se okruh otevře a požadavky selžou okamžitě bez pokusu o provedení operace, což umožňuje obnovení služby.
Fronta nedoručených zpráv Speciální fronta, která ukládá zprávy, které nelze úspěšně zpracovat po několika pokusech. Zabraňuje problematickým zprávám blokovat hlavní frontu zpracování, přičemž je uchovává pro prošetření a vyřešení.
Exponenciální odstup Strategie opakování, ve které se doba čekání mezi opakovanými pokusy zvyšuje exponenciálně, například 3 sekundy, 12 sekund, 30 sekund. Pomáhá zabránit zahlcení obnovující se služby opakovanými požadavky.
Idempotentní Vlastnost operace, která vytváří stejný výsledek bez ohledu na to, kolikrát se spustí. Důležité pro logiku opakování, aby se zabránilo nežádoucím vedlejším účinkům při opakování operací.
Jitter Náhodné zpoždění je přidáno do intervalů opakovaných pokusů, aby se zabránilo tomu, že by se více klientů pokoušelo znovu současně. Pomáhá vyhnout se synchronizovaným bouřím opětovných pokusů, které by mohly zahltit obnovující se službu.
Zásady opakování Kombinace všech prvků strategie opakování, včetně mechanismu detekce, typu intervalu, hodnot skutečných intervalů a počtu opakovaných pokusů Definuje, jak aplikace reaguje na přechodné selhání.
Omezování Postup omezení rychlosti požadavků na službu nebo prostředek za účelem ochrany před přetížením Při překročení limitů často dochází k přechodným chybám, které vyžadují vhodné strategie opakování.
Přerušení zápasu Maximální doba trvání čekání na dokončení operace před tím, než ji pokládáme za neúspěšnou. Při návrhu strategií opakování zvažte vypršení časových limitů, abyste se vyhnuli překročení celkového povoleného času.
Přechodná chyba Dočasné selhání, které se automaticky opravuje a při opakování po vhodném zpoždění pravděpodobně proběhne úspěšně. Mezi příklady patří momentální ztráta sítě, nedostupnost služby nebo vypršení časových limitů kvůli zaneprázdněným službám.

Přechodné chyby

Přechodné poruchy se mohou objevit v jakémkoli prostředí, na jakékoli platformě nebo operačním systému a v jakémkoli druhu aplikace. U řešení, která běží v místní infrastruktuře, se výkon a dostupnost aplikace a jejích komponent obvykle spravují prostřednictvím nákladné a často nedostatečně používané redundance hardwaru a komponenty a prostředky se nacházejí blízko sebe. Tento přístup snižuje pravděpodobnost selhání, ale přechodné chyby mohou stále nastat, protože můžou dojít k výpadkům způsobeným nepředvídatelnými událostmi, jako jsou problémy s externím napájením nebo sítí nebo scénáře havárie.

Hostování cloudu, včetně systémů privátního cloudu, může nabízet vyšší celkovou dostupnost pomocí sdílených prostředků, redundance, automatického převzetí služeb při selhání a dynamického přidělování prostředků napříč mnoha komoditním výpočetním uzly. Z důvodu povahy cloudových prostředí ale pravděpodobně dojde k přechodným chybám. Existuje několik důvodů:

  • Mnoho prostředků v cloudovém prostředí se sdílí a přístup k těmto prostředkům podléhá omezování, aby bylo možné prostředky chránit. Některé služby odmítnou připojení, když zatížení vzroste na určitou úroveň nebo když dosáhnete maximální propustnosti, aby bylo možné zpracovávat stávající požadavky a udržovat výkon služby pro všechny uživatele. Omezování výkonu pomáhá udržovat kvalitu služby pro sousedy a další nájemníky, kteří používají sdílené zdroje.

  • Cloudová prostředí používají velké množství komoditních hardwarových jednotek. Poskytují výkon dynamickým rozdělením zatížení mezi několik výpočetních jednotek a komponent infrastruktury. Zajišťují spolehlivost automatickým recyklací nebo nahrazením jednotek, které selhaly. Kvůli této dynamické povaze může občas dojít k přechodným chybám a dočasným selháním připojení.

  • Mezi aplikací a prostředky a službami, které používá, často existuje více hardwarových komponent, včetně síťové infrastruktury, jako jsou směrovače a nástroje pro vyrovnávání zatížení. Tato další infrastruktura může příležitostně zavádět další latenci připojení a přechodné chyby připojení.

  • Síťové podmínky mezi klientem a serverem můžou být proměnné, zejména při komunikaci přes internet. I v místních umístěních může vysoké zatížení provozu zpomalit komunikaci a způsobit občasné selhání připojení.

Přechodné poruchy mohou mít významný vliv na vnímanou dostupnost aplikace, i když byla důkladně testována za všech předvídatelných okolností. Pokud chcete zajistit, aby aplikace hostované v cloudu fungovaly spolehlivě, musíte zajistit, aby mohly reagovat na následující výzvy:

  • Aplikace musí být schopna detekovat chyby, když nastanou, a určit, zda jsou poruchy pravděpodobně přechodné, dlouhodobé, nebo se jedná o selhání terminálu. Různé zdroje pravděpodobně vrátí různé reakce, když dojde k poruše, a tyto reakce se mohou také lišit v závislosti na kontextu operace. Například odpověď na chybu při čtení aplikace z úložiště se může lišit od odpovědi pro chybu při zápisu do úložiště. Mnoho prostředků a služeb má dobře zdokumentované smlouvy o přechodných selháních. Pokud ale tyto informace nejsou k dispozici, může být obtížné zjistit povahu chyby a jestli je pravděpodobné, že budou přechodné.

  • Pokud aplikace zjistí, že porucha je pravděpodobně přechodná, musí být schopna operaci zopakovat. Musí také sledovat, kolikrát se operace opakuje.

  • Aplikace musí používat vhodnou strategii pro opakování. Strategie určuje, kolikrát se má aplikace pokusit opakovat, prodlevu mezi každým pokusem a akce, které se mají provést po neúspěšném pokusu. Přiměřený počet pokusů a prodlevu mezi každým z nich je často obtížné určit. Strategie se liší v závislosti na typu zdroje a na aktuálních provozních podmínkách zdroje a aplikace.

Následující pokyny vám mohou pomoci navrhnout vhodné mechanismy zpracování přechodných poruch pro vaše aplikace.

Opětovné pokusy

Zjistěte, zda existuje vestavěný mechanismus opakování

  • Mnoho služeb poskytuje sadu SDK nebo klientskou knihovnu, která obsahuje mechanismus zpracování přechodných chyb. Zásada opakování, kterou používá, je obvykle přizpůsobena povaze a požadavkům cílové služby. Alternativně mohou rozhraní REST pro služby vracet informace, které vám mohou pomoci určit, zda je opakování vhodné a jak dlouho čekat před dalším pokusem o opakování.

  • Měli byste použít vestavěný mechanismus opakování, pokud je k dispozici, pokud nemáte specifické a dobře srozumitelné požadavky, které by jiné chování opakování učinily vhodnější.

Zjistěte, zda je operace vhodná pro opakování

  • Operace opakování provádějte pouze v případě, že jsou chyby přechodné (obvykle indikovány povahou chyby) a pokud existuje alespoň určitá pravděpodobnost, že operace bude při opakování úspěšná. Nemá smysl opakovat operace, které se pokoušejí o neplatný úkon, jako je aktualizace databáze u položky, která neexistuje, nebo žádost o službu či zdroj, které utrpěly fatální chybu.

  • Obecně platí, že opakování implementujete pouze v případě, že můžete určit úplný účinek tohoto a kdy jsou podmínky dobře srozumitelné a lze je ověřit. Jinak nechte volající kód implementovat opakované pokusy. Pamatujte, že chyby vrácené ze zdrojů a služeb mimo vaši kontrolu se mohou časem vyvíjet a možná budete muset znovu přezkoumat logiku detekce přechodných chyb.

  • Při vytváření služeb nebo komponent zvažte implementaci kódů chyb a zpráv, které pomáhají klientům určit, jestli by se měly opakovat neúspěšné operace. Konkrétně uveďte, jestli má klient operaci opakovat (třeba vrácením hodnoty isTransient ) a navrhnout vhodné zpoždění před dalším pokusem o opakování. Pokud vytváříte webovou službu, zvažte vrácení vlastních chyb, které jsou definovány ve vašich smlouvách o poskytování služeb. I když obecní klienti nemusí být schopni tyto chyby číst, jsou užitečné při vytváření vlastních klientů.

Určete vhodný počet a interval opakování

  • Optimalizujte počet opakování a interval podle typu případu použití. Pokud nebude počet opakování dostatečný, aplikace nebude moci operaci dokončit a pravděpodobně selže. Pokud to zkusíte příliš mnohokrát nebo s příliš krátkým intervalem mezi pokusy, může aplikace uchovávat prostředky, jako jsou vlákna, připojení a paměť po dlouhou dobu, což nepříznivě ovlivňuje stav aplikace.

  • Přizpůsobte hodnoty pro časový interval a počet pokusů opakování typu operace. Pokud je operace například součástí interakce uživatele, měl by být interval krátký a mělo by se provést pouze několik pokusů. Pomocí tohoto přístupu se můžete vyhnout tomu, aby uživatelé čekali na odpověď, která obsahuje otevřená připojení a může snížit dostupnost pro ostatní uživatele. Pokud je operace součástí dlouhotrvajícího nebo kritického pracovního postupu, kdy zrušení a restartování procesu je nákladné nebo časově náročné, je vhodné počkat delší dobu mezi pokusy a opakovat vícekrát.

  • Mějte na paměti, že určení vhodných intervalů mezi opakováními je nejobtížnější částí návrhu úspěšné strategie. Typické strategie používají následující typy intervalů opakování:

    • Exponenciální back-off Aplikace čeká krátkou dobu před prvním opakováním a poté exponenciálně prodlužuje dobu mezi každým dalším opakováním. Může například opakovat operaci po 3 sekundách, 12 sekundách, 30 sekundách atd. Pokud chcete tuto strategii dále vylepšit, můžete do exponenciálního odložení přidat jitter. Jitter zavádí náhodné zpoždění pro každý pokus o opakování, což pomáhá zabránit tomu, aby více klientů opakovalo připojení současně a způsobilo tak špičku v zatížení.

    • Přírůstkové intervaly. Aplikace chvíli čeká před prvním opakováním a pak přírůstkově zvýší čas mezi každým dalším opakováním. Může například operaci opakovat po 3 sekundách, 7 sekundách, 13 sekundách atd.

    • Pravidelné intervaly. Aplikace čeká stejnou dobu mezi každým pokusem. Může například operaci opakovat každých 3 sekundy.

    • Okamžité opakování. Někdy je přechodná chyba krátká, pravděpodobně způsobená událostí, jako je kolize síťových paketů nebo špička v hardwarové komponentě. V tomto případě je opakování operace okamžitě vhodné, protože může být úspěšné, pokud je chyba vymazána v době, kdy aplikace potřebuje sestavit a odeslat další požadavek. Nikdy by však nemělo dojít k více než jednomu okamžitému pokusu o opakování. Pokud okamžité opakování selže, měli byste přepnout na alternativní strategie, jako jsou exponenciální ustoupení nebo náhradní akce.

    • Randomizace. Každá z dříve uvedených strategií opakování může zahrnovat randomizaci, aby se zabránilo více instancím klienta, které současně odesílají následné pokusy o opakování. Například jedna instance může operaci opakovat po 3 sekundách, 11 sekundách, 28 sekundách atd., zatímco jiná instance může operaci opakovat po 4 sekundách, 12 sekundách, 26 sekundách atd. Randomizace je užitečná technika, která se dá kombinovat s jinými strategiemi.

  • Obecně platí, že pro operace na pozadí používejte exponenciální back-off s náhodným zpožděním a pro interaktivní operace používejte strategie opakování okamžitého nebo pravidelného intervalu. V obou případech byste měli zvolit zpoždění a počet opakování tak, aby maximální latence pro všechny pokusy opakování byla v rámci požadovaného požadavku na úplnou latenci.

  • Vezměte v úvahu kombinaci všech faktorů, které přispívají k celkovému maximálnímu překročení časového limitu pro opakovanou operaci. Mezi tyto faktory patří doba, kterou trvá neúspěšné připojení k vytvoření odpovědi (obvykle nastavená hodnotou časového limitu v klientovi), zpoždění mezi opakovanými pokusy a maximálním počtem opakování. Součet všech těchto časů může mít za následek dlouhé celkové provozní doby, zvláště když používáte strategii exponenciálního zpoždění, kdy interval mezi opakováními po každém selhání rychle roste. Pokud proces musí splňovat konkrétní dohodu o úrovni služeb (SLA), musí být celková doba provozu včetně všech časových limitů a zpoždění v rámci limitů definovaných v SLA.

  • Neimplementujte příliš agresivní strategie restartování. Jedná se o strategie, které mají příliš krátké intervaly nebo příliš časté opakování. Mohou mít nepříznivý vliv na cílový zdroj nebo službu. Tyto strategie mohou zabránit tomu, aby se prostředek nebo služba zotavila z přetíženého stavu a bude nadále blokovat nebo odmítat požadavky. Výsledkem tohoto scénáře je začarovaný kruh, kdy se zdroji nebo službě posílá stále více požadavků. V důsledku toho je jeho schopnost zotavení dále snížena.

  • Pokud zvolíte intervaly opakování, vezměte v úvahu časový limit operací, abyste se vyhnuli okamžitému spuštění následného pokusu (například pokud je období časového limitu podobné intervalu opakování). Zvažte také, jestli potřebujete zachovat celkovou možnou dobu (časový limit plus intervaly opakování) pod konkrétním celkovým časem. Pokud má operace neobvykle krátký nebo dlouhý časový limit, může časový limit ovlivnit dobu čekání a četnost opakování operace.

  • K optimalizaci počtu opakování a intervalu mezi nimi použijte typ výjimky a všechna data, která obsahuje, nebo kódy chyb a zprávy vrácené službou. Například některé výjimky nebo chybové kódy (jako je kód HTTP 503, Služba není k dispozici, s hlavičkou Retry-After v odpovědi) mohou naznačovat, jak dlouho může chyba trvat, nebo že služba selhala a nebude reagovat na žádné následný pokus.

  • Zvažte použití přístupu dead-letter queue, abyste zajistili, že po vyčerpání všech pokusů o opakování se neztratí žádné informace z příchozího vyvolání.

Vyhněte se antivzorů

  • Ve většině případů se vyhněte implementacím, které obsahují duplicitní vrstvy kódu opakování. Vyhněte se návrhům, které zahrnují kaskádové mechanismy opakování nebo které implementují opakování v každé fázi operace, která zahrnuje hierarchii požadavků, pokud nemáte specifické požadavky, které to vyžadují. Za těchto výjimečných okolností používejte zásady, které zabraňují nadměrnému počtu opakování a zpoždění, a ujistěte se, že rozumíte důsledkům. Řekněme například, že jedna komponenta odešle požadavek na jinou, která pak přistupuje k cílové službě. Pokud implementujete opakování s počtem tří u obou volání, uskuteční se celkem devět pokusů opakování vůči službě. Mnoho služeb a prostředků implementuje vestavěný mechanismus opakování. Měli byste prozkoumat, jak můžete deaktivovat nebo upravit tyto mechanismy, pokud potřebujete implementovat opakování na vyšší úrovni.

  • Nikdy neimplementujte nekonečný mechanismus opakování. Pokud tak učiníte, pravděpodobně zabráníte tomu, aby se prostředek nebo služba zotavila ze situací přetížení a způsobí to, že omezení a odmítnutí připojení budou pokračovat po delší dobu. Použijte omezený počet opakování nebo implementujte vzor, jako je Circuit Breaker, který umožní službě se obnovit.

  • Nikdy neprovádějte okamžitý pokus více než jednou.

  • Nepoužívejte pravidelný interval opakování při přístupu ke službám a prostředkům v Azure, zejména pokud máte velký počet pokusů o opakování. Nejlepším přístupem v tomto scénáři je strategie exponenciálního odsazení se schopností přerušení obvodu.

  • Zabrání souběžnému odesílání opakovaných pokusů více instancemi stejného klienta nebo různých klientů. Pokud k tomuto scénáři pravděpodobně dojde, zaveděte do intervalů opakování randomizaci.

Testování strategií znovuotevření a implementace

  • Plně otestujte svou strategii opakování za co nejširšího souboru okolností, zejména pokud jsou aplikace i cílové prostředky nebo služby, které používá, extrémně zatíženy. Ke kontrole chování během testování můžete:

    • Zahrňte přechodné chyby do techniky chaosu a injektáže chyb tím, že je záměrně zavedete do neprodukčních a produkčních prostředí. Například posílejte neplatné požadavky nebo přidejte kód, který detekuje testovací požadavky a reaguje s různými typy chyb.

    • Vytvořit model prostředku nebo služby, který simuluje řadu chyb, které může vrátit skutečná služba. Zahrňte všechny typy chyb, které je tato vaše strategie opakování navržena detekovat.

    • U vlastních služeb, které vytvoříte a nasadíte, vynuťte výskyt přechodných chyb dočasným vypnutím nebo přetížením služby. (Nepokoušejte se přetížit žádné sdílené prostředky nebo sdílené služby v Azure.)

    • Pomocí knihoven nebo řešení, které zachycují a upravují síťový provoz, můžete replikovat nežádoucí scénáře z automatizovaných testů. Testy mohou například přidat další doby obousměrného zpoždění, zahodit pakety, upravit hlavičky nebo dokonce změnit obsah samotného požadavku. To umožňuje deterministické testování podmnožiny podmínek selhání, včetně přechodných chyb a dalších typů selhání.

    • Při testování odolnosti klientské webové aplikace vůči přechodným chybám použijte vývojářské nástroje prohlížeče nebo schopnost vašeho testovacího rámce podvrhnout nebo blokovat síťové požadavky.

    • Proveďte vysoký zátěžový faktor a souběžné testy, abyste zajistili, že mechanismus opakování a strategie za těchto podmínek správně fungují. Tyto testy také pomáhají zajistit, že opakovaný pokus nebude mít nepříznivý vliv na provoz klienta nebo nezpůsobí křížovou kontaminaci mezi požadavky.

Spravujte konfigurace zásad opakování

  • Zásady opakování jsou kombinací všech prvků vaší strategie opakování. Definuje mechanismus detekce, který určuje, jestli je chyba pravděpodobně přechodná, typ intervalu, který se má použít (například normální, exponenciální zpět a randomizace), hodnoty skutečných intervalů a počet opakování.

  • Implementujte opakování na mnoha místech, a to i v nejjednodušší aplikaci a v každé vrstvě složitějších aplikací. Místo pevného kódování prvků jednotlivých zásad na více místech zvažte použití centrálního bodu k uložení všech zásad. Například uložte hodnoty, jako je interval a počet opakování v konfiguračních souborech aplikace, přečtěte si je za běhu a programově sestavte zásady opakování. To usnadňuje správu nastavení a úpravu a vyladění hodnot tak, aby odpovídaly měnícím se požadavkům a scénářům. Systém však navrhujte tak, aby hodnoty ukládaly místo opakovaného načítání konfiguračního souboru pokaždé, a pokud hodnoty nelze získat z konfigurace, použijte vhodné výchozí hodnoty.

  • Uložte hodnoty, které se používají k sestavení zásad opakování za běhu v konfiguračním systému aplikace, abyste je mohli změnit, aniž byste museli aplikaci restartovat.

  • Využijte integrované nebo výchozí strategie opakování, které jsou dostupné v klientských rozhraních API, která používáte, ale pouze v případě, že jsou vhodné pro váš scénář. Tyto strategie jsou obvykle obecné. V některých scénářích mohou být vše, co potřebujete, ale v jiných scénářích nenabízejí celou škálu možností, které by vyhovovaly vašim konkrétním požadavkům. Chcete-li určit nejvhodnější hodnoty, musíte provést testování, abyste pochopili, jak nastavení ovlivňují vaši aplikaci.

Zaznamenávejte a sledujte přechodné a nepřechodné poruchy

  • Jako součást vaší strategie opakování zahrňte zpracování výjimek a další vybavení, které zaznamenává pokusy o opakování. Občasné přechodné selhání a opakování se očekávají a neindikují problém. Pravidelné a zvyšující se počty opakování jsou však často indikátorem problému, který může způsobit selhání nebo který snižuje výkon a dostupnost aplikace.

  • Přechodné poruchy protokolujte jako záznamy varování, a ne záznamy chyb, aby je monitorovací systémy nezjistily jako chyby aplikace, které by mohly spustit falešné výstrahy.

  • Zvažte uložení hodnoty do položek protokolu, která označuje, zda jsou opakování způsobena omezením ve službě, nebo jinými typy chyb, jako jsou selhání připojení, abyste je mohli během analýzy dat odlišit. Zvýšení počtu chyb omezování je často indikátorem chyby návrhu v aplikaci nebo je nutné přejít na prémiovou službu, která nabízí vyhrazený hardware.

  • Zvažte měření a protokolování celkového uplynulého času pro operace, které zahrnují mechanismus opakování. Tato metrika je dobrým indikátorem celkového vlivu přechodných chyb na dobu odezvy uživatele, latenci procesu a efektivitu případů použití aplikace. Také protokolujte počet opakovaných pokusů, ke kterým dochází, abyste pochopili faktory, které přispívají k době odezvy.

  • Zvažte implementaci telemetrického a monitorovacího systému, který může upozorňovat, když se zvyšuje počet a četnost selhání, průměrný počet opakování nebo celková doba, která uplyne, než operace uspěje.

Spravujte operace, které neustále selhávají

  • Zvažte, jak zacházet s operacemi, které nadále selhávají při každém pokusu. Takové situace jsou nevyhnutelné.

    • I když strategie opakování definuje maximální počet opakování operace, která by se měla opakovat, nezabrání aplikaci v opakování operace se stejným počtem opakování. Pokud například služba zpracování objednávek selže se závažnou chybou, která ji trvale vyřadí z provozu, strategie opakování může zjistit vypršení časového limitu připojení a zvážit, že se jedná o přechodnou chybu. Kód opakuje operaci určitý početkrát a pak se operace vzdá. Pokud ale jiný zákazník zadá objednávku, operace se pokusí znovu, i když se nezdaří pokaždé.

    • Abyste zabránili neustálému opakování operací, které neustále selhávají, měli byste zvážit implementaci zvzoru přerušovače obvodu. Pokud tento vzor použijete, pokud počet selhání v zadaném časovém intervalu překročí prahovou hodnotu, žádosti se okamžitě vrátí volajícímu jako chyby a nedojde k žádnému pokusu o přístup k prostředku nebo službě, který selhal.

    • Aplikace může službu pravidelně testovat, přerušovaně a s dlouhými intervaly mezi požadavky, aby zjistila, kdy bude dostupná. Vhodný interval závisí na faktorech, jako je kritičnost operace a povaha služby. Může to být něco mezi několika minutami a několika hodinami. Když je test úspěšný, aplikace může obnovit normální operace a předat požadavky nově obnovené službě.

    • Mezitím se můžete vrátit k jiné instanci služby (možná v jiném datacentru nebo aplikaci), použít podobnou službu, která nabízí kompatibilní (možná jednodušší) funkce, nebo provést některé alternativní operace na základě naděje, že bude služba brzy dostupná. Může být například vhodné uložit požadavky na službu do fronty nebo úložiště dat a zkusit je později. Nebo můžete být schopni uživatele přesměrovat na alternativní instanci aplikace, snížit výkon aplikace, ale přesto nabídnout přijatelné funkce, nebo uživateli vrátit zprávu s oznámením, že aplikace není aktuálně dostupná.

Optimalizace implementace znovupokusů

  • Při rozhodování o hodnotách počtu pokusů a jejich intervalech pro politiku zvažte, zda je operace v rámci služby nebo zdroje součástí dlouhotrvající nebo vícekrokové operace. Může být obtížné nebo nákladné kompenzovat všechny ostatní provozní kroky, které už byly úspěšné, když jeden selže. V tomto případě může být velmi dlouhý interval a velký počet opakování přijatelný, pokud tato strategie neblokuje jiné operace tím, že zabírá nebo blokuje vzácné prostředky.

  • Zvažte, zda by opakovaný pokus o stejnou operaci mohl způsobit nekonzistence v datech. Pokud se některé části vícekrokového procesu opakují a operace nejsou idempotentní, může dojít k nesrovnalostem. Pokud se například operace, která zvýší hodnotu, opakuje, vytvoří neplatný výsledek. Opakování operace, která odesílá zprávu do fronty, může způsobit nekonzistenci příjemce zprávy, pokud příjemce nemůže rozpoznat duplicitní zprávy. Pokud chcete těmto scénářům zabránit, navrhujte každý krok jako idempotentní operaci. Další informace najdete v tématu Vzory idempotence.

  • Zvažte rozsah operací, které se opakují. Například by mohlo být snazší implementovat kód pro opakování na úrovni, která zahrnuje několik operací, a v případě selhání je zkusit všechny znovu. Tím se však může vyskytnout problémy s idempotencí nebo zbytečné operace vrácení zpět.

  • Pokud zvolíte rozsah opakování, který zahrnuje několik operací, vezměte v úvahu celkovou latenci všech těchto operací při určování intervalů opakování, při sledování uplynulého času operací a před vyvoláním výstrah pro selhání.

  • Zvažte, jak může vaše strategie opětovného pokusu ovlivnit sousedy a další tenanty ve sdílené aplikaci, a při používání sdílených prostředků a služeb. Agresivní zásady opakování můžou způsobit rostoucí počet přechodných chyb pro tyto ostatní uživatele a pro aplikace, které sdílejí prostředky a služby. Podobně může být vaše aplikace ovlivněná zásadami opakování implementovanými jinými uživateli prostředků a služeb. U důležitých obchodních aplikací můžete chtít používat prémiové služby, které nejsou sdílené. Tím získáte větší kontrolu nad zatížením a následným omezováním těchto prostředků a služeb, které vám můžou pomoct odůvodnit dodatečné náklady.

Poznámka:

Další pokyny k kompromisům a rizikům najdete v článku o vzorech opakování.

Usnadnění na platformě Azure

Většina služeb Azure a klientských sad SDK poskytuje mechanismus opakování. Tyto mechanismy se ale liší, protože každá služba má různé charakteristiky a požadavky a každý mechanismus opakování je vyladěný na konkrétní službu. Tato část shrnuje funkce mechanismu opakování pro některé běžně používané služby Azure.

Service Možnosti opakování Konfigurace zásad Scope Funkce telemetrie
Microsoft Entra ID Nativní v knihovně Microsoft Authentication Library (MSAL) Vložené do knihovny MSAL Interní None
Azure Cosmos DB Nativní ve službě Nelze konfigurovat Global TraceSource
Azure Data Lake Storage Nativní v klientovi Nelze konfigurovat Jednotlivé operace None
Azure Event Hubs Nativní v klientovi Programmatic Klient None
Azure IoT Hub Nativní v klientském SDK Programmatic Klient None
Azure Cognitive Search Nativní v klientovi Programmatic Klient ETW nebo vlastní trasování
Azure Service Bus Nativní v klientovi Programmatic NamespaceManager, MessagingFactory a klient Trasování událostí pro Windows
Azure Service Fabric Nativní v klientovi Programmatic Klient None
Azure SQL Database s ADO.NET Polly Deklarativní a programové Jednoduché příkazy nebo bloky kódu Custom
SQL Database s použitím Entity Framework Nativní v klientovi Programmatic Global na AppDomain None
SQL databáze spolu s Entity Framework Core Nativní v klientovi Programmatic Global na AppDomain None
Azure Storage Nativní v klientovi Programmatic Klient a jednotlivé operace TraceSource

Poznámka:

U většiny integrovaných mechanismů opakování Azure v současné době neexistuje způsob, jak použít jiné zásady 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. Jedním ze způsobů, jak vyladit zásady, je analyzovat soubory protokolu a určit typ přechodných chyb, ke kterým dochází.

Example

Příklad, který používá mnoho vzorů probíraných v tomto článku, najdete v modelu spolehlivé webové aplikace pro .NET . Existuje také referenční implementace na GitHubu.

Kontrolní seznam pro spolehlivost

Projděte si kompletní sadu doporučení.

Kontrolní seznam pro spolehlivost

  • Last updated on