Aanbevelingen voor het afhandelen van tijdelijke fouten

  • Artikel

Van toepassing op deze aanbeveling voor de betrouwbaarheidschecklist van Azure Well-Architected Framework:

RE:07 Verbeter de tolerantie en herstelbaarheid van uw workload door zelfbehoud en zelfherstelmaatregelen te implementeren. Bouw mogelijkheden in de oplossing in met behulp van op infrastructuur gebaseerde betrouwbaarheidspatronen en ontwerppatronen op basis van software voor het afhandelen van onderdeelfouten en tijdelijke fouten. Bouw mogelijkheden in het systeem in om fouten met oplossingsonderdelen te detecteren en automatisch corrigerende actie te starten terwijl de workload met volledige of verminderde functionaliteit blijft werken.

Gerelateerde handleidingen:Achtergrondtaken | Zelfbehoud

In deze handleiding worden de aanbevelingen beschreven voor het afhandelen van tijdelijke fouten in uw cloudtoepassingen. Alle toepassingen die met externe services en bronnen communiceren moeten gevoelig zijn voor tijdelijke fouten. Dit geldt met name voor toepassingen die worden uitgevoerd in de cloud, waarbij vanwege de aard van de omgeving en connectiviteit via internet dit type fout waarschijnlijk vaker voorkomt. Tijdelijke fouten zijn onder andere het kortstondige verlies van de netwerkverbinding met onderdelen en services, het tijdelijk niet beschikbaar zijn van een service en time-outs die optreden wanneer een service bezet is. Deze fouten worden vaak automatisch gecorrigeerd, dus als de actie wordt herhaald na een geschikte vertraging, is de kans groot dat deze slaagt.

Dit artikel bevat algemene richtlijnen voor het afhandelen van tijdelijke fouten. Zie het patroon voor opnieuw proberen voor informatie over het afhandelen van tijdelijke fouten. Wanneer u Azure-services gebruikt, raadpleegt u de richtlijnen voor opnieuw proberen voor Azure-services.

Belangrijke ontwerpstrategieën

Tijdelijke fouten kunnen optreden in elke omgeving, op alle platforms en besturingssystemen, en in elke toepassing. Voor oplossingen die worden uitgevoerd op lokale on-premises infrastructuur, worden de prestaties en beschikbaarheid van de toepassing en de bijbehorende onderdelen doorgaans gehandhaafd via dure en vaak te weinig gebruikte hardwareredundantie, en bevinden onderdelen en resources zich dicht bij elkaar. Deze benadering maakt storingen minder waarschijnlijk, maar tijdelijke fouten kunnen nog steeds optreden, evenals storingen die worden veroorzaakt door onvoorziene gebeurtenissen zoals externe voeding of netwerkproblemen, of door noodscenario's.

Cloudhosting, inclusief privécloudsystemen, kan een hogere algemene beschikbaarheid bieden door gebruik te maken van gedeelde resources, redundantie, automatische failover en dynamische resourcetoewijzing op veel rekenknooppunten. Vanwege de aard van cloudomgevingen is de kans echter groter dat tijdelijke fouten optreden. Hiervoor zijn diverse redenen:

  • Veel resources in een cloudomgeving worden gedeeld en de toegang tot deze resources is onderhevig aan beperking om de resources te beveiligen. Sommige services weigeren verbindingen wanneer de belasting toeneemt tot een bepaald niveau of wanneer een maximale doorvoersnelheid wordt bereikt, om de verwerking van bestaande aanvragen mogelijk te maken en de prestaties van de service voor alle gebruikers te behouden. Beperking helpt bij het handhaven van de kwaliteit van de service voor buren en andere tenants die gebruikmaken van de gedeelde resource.

  • Cloudomgevingen maken gebruik van een groot aantal basishardware-eenheden. Ze leveren prestaties door de belasting dynamisch te verdelen over meerdere rekeneenheden en infrastructuuronderdelen. Ze leveren betrouwbaarheid door defecte eenheden automatisch te recyclen of te vervangen. Vanwege deze dynamische aard kunnen tijdelijke fouten en tijdelijke verbindingsfouten af en toe optreden.

  • Er zijn vaak meer hardwareonderdelen, waaronder netwerkinfrastructuur zoals routers en load balancers, tussen de toepassing en de resources en services die worden gebruikt. Deze aanvullende infrastructuur kan soms extra verbindingslatentie en tijdelijke verbindingsfouten veroorzaken.

  • De netwerkomstandigheden tussen de client en de server kunnen variabel zijn, met name wanneer de communicatie via internet gaat. Zelfs op on-premises locaties kan zware verkeersbelasting de communicatie vertragen en onregelmatige verbindingsfouten veroorzaken.

Uitdagingen

Tijdelijke fouten kunnen een aanzienlijk effect hebben op de waargenomen beschikbaarheid van een toepassing, zelfs als deze grondig is getest onder alle voorzienbare omstandigheden. Om ervoor te zorgen dat in de cloud gehoste toepassingen betrouwbaar werken, moet u ervoor zorgen dat ze kunnen reageren op de volgende uitdagingen:

  • De toepassing moet fouten kunnen detecteren wanneer ze optreden en bepalen of de fouten waarschijnlijk tijdelijk zijn, langdurig zijn of terminale fouten zijn. Verschillende resources retourneren waarschijnlijk verschillende antwoorden wanneer er een fout optreedt, en deze antwoorden kunnen ook variëren, afhankelijk van de context van de bewerking. Het antwoord op een fout wanneer de toepassing uit de opslag leest, kan bijvoorbeeld verschillen van het antwoord op een fout wanneer deze naar de opslag wordt geschreven. Veel resources en services hebben goed gedocumenteerde contracten voor tijdelijke fouten. Wanneer dergelijke informatie echter niet beschikbaar is, kan het moeilijk zijn om de aard van de fout te achterhalen en of deze waarschijnlijk tijdelijk is.

  • De toepassing moet de bewerking opnieuw kunnen proberen als wordt vastgesteld dat de fout waarschijnlijk tijdelijk is. Er moet ook worden bijgehouden hoe vaak de bewerking opnieuw wordt uitgevoerd.

  • De toepassing moet een geschikte strategie gebruiken voor nieuwe pogingen. De strategie geeft het aantal keren aan dat de toepassing opnieuw moet proberen, de vertraging tussen elke poging en de acties die moeten worden uitgevoerd na een mislukte poging. Het juiste aantal pogingen en de vertraging tussen elke poging zijn vaak moeilijk te bepalen. De strategie is afhankelijk van het type resource en de huidige bedrijfsomstandigheden van de resource en de toepassing.

Algemene richtlijnen

De volgende richtlijnen kunnen u helpen bij het ontwerpen van geschikte mechanismen voor het afhandelen van tijdelijke fouten voor uw toepassingen.

Bepalen of er een ingebouwd mechanisme voor opnieuw proberen is

  • Veel services hebben een SDK of clientbibliotheek die een mechanisme voor het afhandelen van tijdelijke fouten bevat. Het beleid voor opnieuw proberen is gewoonlijk aangepast aan de aard en de vereisten van de doelservice. Rest-interfaces voor services kunnen ook informatie retourneren waarmee u kunt bepalen of een nieuwe poging geschikt is en hoe lang moet worden gewacht voor de volgende poging.

  • U moet het ingebouwde mechanisme voor opnieuw proberen gebruiken wanneer dit beschikbaar is, tenzij u specifieke en goed begrepen vereisten hebt die een ander gedrag voor opnieuw proberen geschikter maken.

Bepalen of de bewerking geschikt is voor opnieuw proberen

  • Voer bewerkingen voor nieuwe pogingen alleen uit wanneer de fouten tijdelijk zijn (meestal aangegeven door de aard van de fout) en wanneer er ten minste een zekere kans is dat de bewerking slaagt wanneer het opnieuw wordt geprobeerd. Het heeft geen zin om bewerkingen opnieuw uit te voeren die een ongeldige bewerking proberen uit te voeren, zoals een database-update van een item dat niet bestaat of een aanvraag naar een service of resource die een onherstelbare fout heeft opgetreden.

  • Over het algemeen kunt u nieuwe pogingen alleen implementeren wanneer u het volledige effect hiervan kunt bepalen en wanneer de voorwaarden goed zijn begrepen en kunnen worden gevalideerd. Anders laat u de aanroepende code nieuwe pogingen implementeren. Houd er rekening mee dat de fouten die worden geretourneerd door resources en services buiten uw controle, in de loop van de tijd kunnen veranderen en dat u mogelijk de logica voor tijdelijke foutdetectie opnieuw moet bekijken.

  • Wanneer u services of onderdelen maakt, kunt u overwegen foutcodes en berichten te implementeren waarmee clients kunnen bepalen of ze mislukte bewerkingen opnieuw moeten proberen. Geef met name aan of de client de bewerking opnieuw moet proberen (bijvoorbeeld door een isTransient-waarde te retourneren) en stel een geschikte vertraging voor de volgende poging voor. Als u een webservice bouwt, kunt u overwegen om aangepaste fouten te retourneren die zijn gedefinieerd in uw servicecontracten. Hoewel algemene clients deze fouten mogelijk niet kunnen lezen, zijn ze nuttig bij het maken van aangepaste clients.

Een geschikt aantal nieuwe pogingen en het juiste interval bepalen

  • Optimaliseer het aantal nieuwe pogingen en het interval naar het type use-case. Als u het niet vaak genoeg opnieuw probeert, kan de toepassing de bewerking niet voltooien en mislukt deze waarschijnlijk. Als u het te vaak opnieuw probeert, of met een te kort interval tussen pogingen, kan de toepassing resources zoals threads, verbindingen en geheugen gedurende lange perioden bewaren, wat een negatieve invloed heeft op de status van de toepassing.

  • Pas waarden voor het tijdsinterval en het aantal nieuwe pogingen aan het type bewerking aan. Als de bewerking bijvoorbeeld deel uitmaakt van een gebruikersinteractie, moet het interval kort zijn en moeten er slechts enkele nieuwe pogingen worden gedaan. Met deze methode kunt u voorkomen dat gebruikers moeten wachten op een antwoord, dat open verbindingen bevat en de beschikbaarheid voor andere gebruikers kan verminderen. Als de bewerking deel uitmaakt van een langdurige of kritieke werkstroom, waarbij het annuleren en opnieuw starten van het proces duur of tijdrovend is, is het raadzaam om langer te wachten tussen pogingen en het opnieuw proberen.

  • Houd er rekening mee dat het bepalen van de juiste intervallen tussen nieuwe pogingen het moeilijkste onderdeel is van het ontwerpen van een succesvolle strategie. Voor typische strategieën wordt gebruikgemaakt van de volgende intervaltypen:

    • Exponentieel terug. De toepassing wacht kort voordat de eerste nieuwe poging wordt uitgevoerd, waarna de tijd tussen elke volgende nieuwe poging exponentieel wordt verhoogd. De bewerking kan bijvoorbeeld opnieuw worden uitgevoerd na 3, 12 seconden, 30 seconden, enzovoort.

    • Incrementele intervallen. De toepassing wacht een korte tijd voordat de eerste nieuwe poging wordt uitgevoerd en verhoogt vervolgens stapsgewijs de tijd tussen elke volgende nieuwe poging. De bewerking kan bijvoorbeeld opnieuw worden uitgevoerd na 3 seconden, 7 seconden, 13 seconden, enzovoort.

    • Regelmatige intervallen. Het interval tussen pogingen is telkens even lang. Het kan bijvoorbeeld elke 3 seconden opnieuw worden geprobeerd om de bewerking uit te voeren.

    • Onmiddellijk opnieuw proberen. Soms is een tijdelijke fout kort, mogelijk veroorzaakt door een gebeurtenis zoals een netwerkpakketconflict of een piek in een hardwareonderdeel. In dit geval is het raadzaam om de bewerking onmiddellijk opnieuw uit te voeren, omdat deze kan slagen als de fout wordt verhelderd in de tijd dat de toepassing nodig heeft om de volgende aanvraag te verzamelen en te verzenden. Er mag echter nooit meer dan één onmiddellijke nieuwe poging zijn. U moet overschakelen naar alternatieve strategieën, zoals exponentiële back-off- of terugvalacties, als de onmiddellijke nieuwe poging mislukt.

    • Randomisatie. Elk van de strategieën voor opnieuw proberen die eerder zijn vermeld, kan een willekeurige toewijzing bevatten om te voorkomen dat meerdere exemplaren van de client volgende nieuwe pogingen tegelijk verzenden. Het ene exemplaar kan de bewerking bijvoorbeeld opnieuw proberen na 3, 11 seconden, 28 seconden, enzovoort, terwijl een ander exemplaar de bewerking na 4 seconden, 12 seconden, 26 seconden, enzovoort opnieuw probeert uit te voeren. Randomisatie is een handige techniek die kan worden gecombineerd met andere strategieën.

  • Gebruik als algemene richtlijn een exponentieel back-off-strategie voor bewerkingen op de achtergrond en gebruik strategieën voor onmiddellijke of regelmatige intervalherhaling voor interactieve bewerkingen. In beide gevallen dient u de vertraging en het aantal pogingen zodanig te kiezen dat de maximale latentie voor alle nieuwe pogingen zich binnen het vereiste bereik voor end-to-endlatentie bevindt.

  • Rekening houden met de combinatie van alle factoren die bijdragen aan de totale maximale time-out voor een opnieuw geprobeerde bewerking. Deze factoren omvatten de tijd die een mislukte verbinding nodig heeft om een antwoord te produceren (meestal ingesteld op een time-outwaarde in de client), de vertraging tussen nieuwe pogingen en het maximum aantal nieuwe pogingen. Het totaal van al deze tijden kan leiden tot lange algemene bewerkingstijden, met name wanneer u een strategie voor exponentieel uitstel gebruikt, waarbij het interval tussen nieuwe pogingen na elke fout snel toeneemt. Als een proces moet voldoen aan een specifieke SLA (Service Level Agreement), moet de totale bewerkingstijd, inclusief alle time-outs en vertragingen, binnen de limieten vallen die zijn gedefinieerd in de SLA.

  • Implementeer geen te agressieve strategieën voor opnieuw proberen. Dit zijn strategieën met intervallen die te kort zijn of nieuwe pogingen die te vaak worden uitgevoerd. Ze kunnen een nadelig effect hebben op de doelresource of -service. Deze strategieën kunnen voorkomen dat de resource of service wordt hersteld van de overbelaste status en dat aanvragen blijven blokkeren of weigeren. Dit scenario resulteert in een vicieuze cirkel, waarbij steeds meer aanvragen naar de resource of service worden verzonden. Als gevolg hiervan wordt het vermogen om te herstellen verder verminderd.

  • Houd rekening met de time-out van de bewerkingen wanneer u intervallen voor nieuwe pogingen kiest om te voorkomen dat een volgende poging onmiddellijk wordt gestart (bijvoorbeeld als de time-outperiode vergelijkbaar is met het interval voor opnieuw proberen). Overweeg ook of u de totale mogelijke periode (de time-out plus de intervallen voor opnieuw proberen) onder een bepaalde totale tijd wilt houden. Als een bewerking een ongebruikelijk korte of lange time-out heeft, kan de time-out van invloed zijn op hoe lang moet worden gewacht en hoe vaak de bewerking opnieuw moet worden uitgevoerd.

  • Gebruik het type uitzondering en eventuele gegevens die deze bevatten, of de foutcodes en berichten die door de service worden geretourneerd, om het aantal nieuwe pogingen en het interval ertussen te optimaliseren. Sommige uitzonderingen of foutcodes (zoals de HTTP-code 503, Service niet beschikbaar, met een Retry-After-header in het antwoord) kunnen bijvoorbeeld aangeven hoe lang de fout kan duren of dat de service is mislukt en niet reageert op een volgende poging.

  • Overweeg een wachtrij met onbestelbare berichten te gebruiken om ervoor te zorgen dat alle informatie van de binnenkomende aanroep niet verloren gaat nadat alle nieuwe pogingen zijn uitgeput.

Antipatronen vermijden

  • Vermijd in de meeste gevallen implementaties met dubbele lagen van code voor opnieuw proberen. Vermijd ontwerpen die trapsgewijze mechanismen voor opnieuw proberen bevatten of die nieuwe pogingen implementeren in elke fase van een bewerking die een hiërarchie van aanvragen omvat, tenzij u specifieke vereisten hebt waarvoor dit vereist is. Onder dergelijke uitzonderlijke omstandigheden gebruikt u beleid waarmee overmatige aantallen nieuwe pogingen en vertragingen worden voorkomen en dient u zeker te zijn van de gevolgen. Stel dat het ene onderdeel een aanvraag indient bij een ander onderdeel, dat vervolgens toegang krijgt tot de doelservice. Als u nieuwe pogingen implementeert met een aantal van drie op beide aanroepen, zijn er in totaal negen nieuwe pogingen voor de service. Veel services en resources implementeren een ingebouwd mechanisme voor opnieuw proberen. U moet onderzoeken hoe u deze mechanismen kunt uitschakelen of wijzigen als u nieuwe pogingen op een hoger niveau wilt implementeren.

  • Implementeer nooit een mechanisme waarbij eindeloos nieuwe pogingen worden uitgevoerd. Als u dit doet, voorkomt u waarschijnlijk dat de resource of service wordt hersteld van overbelastingssituaties en dat beperking en geweigerde verbindingen gedurende langere tijd worden voortgezet. Gebruik een eindig aantal nieuwe pogingen of implementeer een patroon zoals Circuitonderbreker om de service te laten herstellen.

  • Voer een onmiddellijke nieuwe poging nooit vaker dan eenmaal uit.

  • Vermijd het gebruik van een regelmatig interval voor opnieuw proberen wanneer u toegang krijgt tot services en resources in Azure, met name wanneer u een groot aantal nieuwe pogingen hebt. De beste benadering in dit scenario is een exponentiële back-off-strategie met een circuitbrekende mogelijkheid.

  • Voorkom dat meerdere exemplaren van dezelfde client of meerdere exemplaren van verschillende clients gelijktijdig nieuwe pogingen verzenden. Als dit scenario zich waarschijnlijk zal voordoen, voert u randomisatie in de intervallen voor nieuwe pogingen in.

Uw strategie en implementatie voor opnieuw proberen testen

  • Test uw strategie voor opnieuw proberen volledig onder een zo breed mogelijke set omstandigheden, met name wanneer zowel de toepassing als de doelresources of -services die worden gebruikt, onder extreme belasting staan. Als u tijdens het testen het gedrag wilt controleren, kunt u:

    • Injecteer tijdelijke en niet-tijdelijke fouten in de service. Verzend bijvoorbeeld ongeldige aanvragen of voeg code toe waarmee testaanvragen worden gedetecteerd en waarop met verschillende typen fouten wordt gereageerd.

    • Maak een mockup van de resource of service die een reeks fouten retourneert die de echte service mogelijk retourneert. Bedek alle soorten fouten die uw strategie voor opnieuw proberen is ontworpen om te detecteren.

    • Voor aangepaste services die u maakt en implementeert, forceert u tijdelijke fouten door de service tijdelijk uit te schakelen of te overbelasten. (Probeer geen gedeelde resources of gedeelde services in Azure te overbelasten.)

    • Gebruik bibliotheken of oplossingen die netwerkverkeer onderscheppen en wijzigen om ongunstige scenario's van uw geautomatiseerde tests te repliceren. De tests kunnen bijvoorbeeld extra retourtijden toevoegen, pakketten verwijderen, headers wijzigen of zelfs de hoofdtekst van de aanvraag zelf wijzigen. Dit maakt het deterministisch testen van een subset van de foutvoorwaarden mogelijk, voor tijdelijke fouten en andere soorten fouten.

    • Wanneer u de tolerantie van een clientwebtoepassing voor tijdelijke fouten test, gebruikt u de ontwikkelhulpprogramma's van de browser of de mogelijkheid van uw testframework om netwerkaanvragen te simulteren of te blokkeren .

    • Voer tests met een hoge belastingsfactor en gelijktijdige tests uit om ervoor te zorgen dat het mechanisme en de strategie voor opnieuw proberen correct werken onder deze omstandigheden. Deze tests helpen er ook voor te zorgen dat de nieuwe poging geen nadelig effect heeft op de werking van de client of kruisbesmetting tussen aanvragen veroorzaakt.

Configuraties voor beleid voor opnieuw proberen beheren

  • Een beleid voor opnieuw proberen is een combinatie van alle elementen van uw strategie voor opnieuw proberen. Het definieert het detectiemechanisme dat bepaalt of een fout waarschijnlijk tijdelijk is, het type interval dat moet worden gebruikt (zoals regelmatige, exponentiële back-off en randomisatie), de werkelijke intervalwaarden en het aantal keren dat opnieuw moet worden geprobeerd.

  • Implementeer nieuwe pogingen op veel plaatsen, zelfs in de eenvoudigste toepassing en in elke laag van complexere toepassingen. In plaats van de elementen van elk beleid op meerdere locaties te coderen, kunt u overwegen om een centraal punt te gebruiken om alle beleidsregels op te slaan. Sla bijvoorbeeld waarden op zoals het interval en het aantal nieuwe pogingen in toepassingsconfiguratiebestanden, lees ze tijdens runtime en bouw het beleid voor opnieuw proberen programmatisch. Dit maakt het eenvoudiger om de instellingen te beheren en de waarden te wijzigen en af te stemmen om te reageren op veranderende vereisten en scenario's. Ontwerp het systeem echter om de waarden op te slaan in plaats van telkens een configuratiebestand opnieuw te lezen en gebruik geschikte standaardwaarden als de waarden niet kunnen worden verkregen uit de configuratie.

  • Sla de waarden op die worden gebruikt om het beleid voor opnieuw proberen tijdens runtime op te bouwen in het configuratiesysteem van de toepassing, zodat u ze kunt wijzigen zonder dat u de toepassing opnieuw hoeft te starten.

  • Profiteer van ingebouwde of standaardstrategieën voor opnieuw proberen die beschikbaar zijn in de client-API's die u gebruikt, maar alleen wanneer ze geschikt zijn voor uw scenario. Deze strategieën zijn doorgaans algemeen. In sommige scenario's zijn ze mogelijk alles wat u nodig hebt, maar in andere scenario's bieden ze niet het volledige scala aan opties die voldoen aan uw specifieke vereisten. Als u de meest geschikte waarden wilt bepalen, moet u tests uitvoeren om te begrijpen hoe de instellingen van invloed zijn op uw toepassing.

Tijdelijke en niet-tijdelijke fouten registreren en bijhouden

  • Neem als onderdeel van uw strategie voor opnieuw proberen de afhandeling van uitzonderingen en andere instrumentatie op waarmee nieuwe pogingen worden geregistreerd. Een incidentele tijdelijke fout en nieuwe pogingen worden verwacht en duiden niet op een probleem. Regelmatige en toenemende aantallen nieuwe pogingen zijn echter vaak een indicator van een probleem dat een fout kan veroorzaken of dat de prestaties en beschikbaarheid van toepassingen verslechtert.

  • Leg tijdelijke fouten vast als waarschuwingsvermeldingen in plaats van als foutvermeldingen, zodat bewakingssystemen ze niet detecteren als toepassingsfouten die mogelijk valse waarschuwingen activeren.

  • U kunt een waarde in uw logboekvermeldingen opslaan die aangeeft of nieuwe pogingen worden veroorzaakt door beperking in de service of door andere soorten fouten, zoals verbindingsfouten, zodat u deze kunt onderscheiden tijdens de analyse van de gegevens. Een toename in het aantal beperkingsfouten is vaak een aanwijzing van een ontwerpfout in de toepassing of duidt op de behoefte aan een premium service met speciale hardware.

  • Overweeg om de totale verstreken tijden te meten en te registreren voor bewerkingen die een mechanisme voor opnieuw proberen bevatten. Deze metrische waarde is een goede indicator van het algehele effect van tijdelijke fouten op de reactietijden van gebruikers, proceslatentie en de efficiëntie van toepassingsgebruiksscenario's. Registreer ook het aantal nieuwe pogingen dat plaatsvindt, zodat u inzicht hebt in de factoren die bijdragen aan de reactietijd.

  • Overweeg het implementeren van een telemetrie- en bewakingssysteem dat waarschuwingen kan genereren wanneer het aantal en het aantal fouten, het gemiddelde aantal nieuwe pogingen of de totale tijd die is verstreken voordat bewerkingen slagen, toeneemt.

Bewerkingen beheren die voortdurend mislukken

  • Denk na over het afhandelen van bewerkingen die bij elke poging blijven mislukken. Dit soort situaties zijn onvermijdelijk.

    • Hoewel een strategie voor opnieuw proberen het maximum aantal keren definieert dat een bewerking opnieuw moet worden geprobeerd, voorkomt dit niet dat de toepassing de bewerking opnieuw herhaalt met hetzelfde aantal nieuwe pogingen. Als een orderverwerkingsservice bijvoorbeeld mislukt met een fatale fout waardoor deze permanent buiten werking treedt, kan de strategie voor opnieuw proberen een time-out voor de verbinding detecteren en deze als een tijdelijke fout beschouwen. De code probeert de bewerking een opgegeven aantal keer opnieuw en geeft vervolgens op. Wanneer een andere klant echter een bestelling plaatst, wordt de bewerking opnieuw geprobeerd, ook al mislukt deze elke keer.

    • Als u continu nieuwe pogingen wilt voorkomen voor bewerkingen die voortdurend mislukken, moet u overwegen het circuitonderbrekerpatroon te implementeren. Wanneer u dit patroon gebruikt en het aantal fouten binnen een opgegeven tijdvenster een drempelwaarde overschrijdt, worden aanvragen onmiddellijk als fouten naar de aanroeper geretourneerd en wordt er geen poging uitgevoerd om toegang te krijgen tot de mislukte resource of service.

    • De toepassing kan de service periodiek testen, af en toe en met lange intervallen tussen aanvragen, om te detecteren wanneer deze beschikbaar is. Een geschikt interval is afhankelijk van factoren zoals de ernst van de bewerking en de aard van de service. Dit kan een paar minuten tot enkele uren duren. Wanneer de test is geslaagd, kan de toepassing de normale bewerkingen hervatten en aanvragen doorgeven aan de zojuist herstelde service.

    • In de tussentijd kunt u mogelijk terugvallen op een ander exemplaar van de service (misschien in een ander datacenter of in een andere toepassing), een vergelijkbare service gebruiken die compatibele (misschien eenvoudigere) functionaliteit biedt, of een aantal alternatieve bewerkingen uitvoeren op basis van de hoop dat de service binnenkort beschikbaar zal zijn. Het kan bijvoorbeeld handig zijn om aanvragen voor de service op te slaan in een wachtrij of gegevensarchief en deze later opnieuw te proberen. Of u kunt de gebruiker omleiden naar een alternatief exemplaar van de toepassing, de prestaties van de toepassing verminderen maar nog steeds acceptabele functionaliteit bieden of gewoon een bericht naar de gebruiker retourneren om aan te geven dat de toepassing momenteel niet beschikbaar is.

Andere overwegingen

  • Wanneer u de waarden voor het aantal nieuwe pogingen en de intervallen voor nieuwe pogingen voor een beleid bepaalt, moet u overwegen of de bewerking op de service of resource deel uitmaakt van een langdurige bewerking of een bewerking met meerdere stappen. Het kan moeilijk of duur zijn om alle andere operationele stappen te compenseren die al zijn geslaagd wanneer er een mislukt. In dit geval kunnen een zeer lang interval en een groot aantal nieuwe pogingen acceptabel zijn, zolang die strategie geen andere bewerkingen blokkeert door schaarse resources vast te houden of te vergrendelen.

  • Overweeg of het opnieuw proberen van dezelfde bewerking inconsistenties in de gegevens kan veroorzaken. Als sommige delen van een proces met meerdere stappen worden herhaald en de bewerkingen niet idempotent zijn, kunnen inconsistenties optreden. Als bijvoorbeeld een bewerking waarbij een waarde wordt verhoogd, wordt herhaald, wordt er een ongeldig resultaat gegenereerd. Het herhalen van een bewerking waarmee een bericht naar een wachtrij wordt verzonden, kan leiden tot inconsistentie in de berichtconsumer als de consument geen dubbele berichten kan detecteren. Om deze scenario's te voorkomen, ontwerpt u elke stap als een idempotente bewerking. Zie Idempotentiepatronen voor meer informatie.

  • Houd rekening met het bereik van bewerkingen die opnieuw worden geprobeerd. Het kan bijvoorbeeld eenvoudiger zijn om code voor opnieuw proberen te implementeren op een niveau dat verschillende bewerkingen omvat en deze allemaal opnieuw uit te voeren als er een mislukt. Dit kan echter leiden tot idempotentieproblemen of onnodige terugdraaibewerkingen.

  • Als u een bereik voor opnieuw proberen kiest dat meerdere bewerkingen omvat, moet u rekening houden met de totale latentie van alle bewerkingen wanneer u intervallen voor nieuwe pogingen bepaalt, wanneer u de verstreken tijden van de bewerking bewaakt en voordat u waarschuwingen voor fouten genereert.

  • Bedenk hoe uw strategie voor opnieuw proberen van invloed kan zijn op buren en andere tenants in een gedeelde toepassing en wanneer u gedeelde resources en services gebruikt. Een agressief beleid voor opnieuw proberen kan een verhoogd aantal tijdelijke fouten tot gevolg hebben voor de andere gebruikers en voor toepassingen die de resources en services delen. Op dezelfde manier kan uw toepassing worden beïnvloed door het beleid voor opnieuw proberen dat is geïmplementeerd door andere gebruikers van de resources en services. Voor bedrijfskritieke toepassingen wilt u mogelijk premium-services gebruiken die niet worden gedeeld. Dit geeft u meer controle over de belasting en de daaruit voortvloeiende beperking van deze resources en services, waardoor de extra kosten kunnen worden gerechtvaardigd.

Notitie

Zie Problemen en overwegingen in het artikel Patroon voor opnieuw proberen voor meer hulp bij afwegingen en risico's.

Azure-facilitering

De meeste Azure-services en client-SDK's bieden een mechanisme voor opnieuw proberen. Deze mechanismen verschillen echter omdat elke service verschillende kenmerken en vereisten heeft en elk mechanisme voor opnieuw proberen is afgestemd op de specifieke service. In deze sectie vindt u een overzicht van de functies van het mechanisme voor opnieuw proberen voor een aantal veelgebruikte Azure-services.

Service Mogelijkheden voor opnieuw proberen Beleidsconfiguratie Bereik Telemetriefuncties
Microsoft Entra ID Systeemeigen in de Microsoft Authentication Library (MSAL) Ingesloten in de MSAL-bibliotheek Intern Geen
Azure Cosmos DB Systeemeigen in de service Niet configureerbaar Globaal TraceSource
Azure Data Lake Storage Systeemeigen in de client Niet configureerbaar Afzonderlijke bewerkingen Geen
Azure Event Hubs Systeemeigen in de client Via programmacode Client Geen
Azure IoT Hub Systeemeigen in de client-SDK Via programmacode Client Geen
Azure Cache voor Redis Systeemeigen in de client Via programmacode Client TextWriter
Azure Cognitive Search Systeemeigen in de client Via programmacode Client ETW of aangepast
Azure Service Bus Systeemeigen in de client Via programmacode NamespaceManager, MessagingFactory en client ETW
Azure Service Fabric Systeemeigen in de client Via programmacode Client Geen
Azure SQL database met ADO.NET Polly Declaratief en via programmacode Losse instructies of codeblokken Aangepast telefoonnummer
SQL Database met Entity Framework Systeemeigen in de client Via programmacode Algemeen per toepassingsdomein Geen
SQL-Database met Entity Framework Core Systeemeigen in de client Via programmacode Algemeen per toepassingsdomein Geen
Azure Storage Systeemeigen in de client Via programmacode Client en individuele bewerkingen TraceSource

Notitie

Voor de meeste ingebouwde azure-mechanismen voor opnieuw proberen is er momenteel geen manier om een ander beleid voor opnieuw proberen toe te passen voor verschillende soorten fouten of uitzonderingen. U moet een beleid configureren dat de optimale gemiddelde prestaties en beschikbaarheid biedt. Een manier om uw beleid af te stemmen, is door logboekbestanden te analyseren om te bepalen welk type tijdelijke fouten optreden.

Voorbeeld

Zie Betrouwbaar web-app-patroon voor .NET voor een voorbeeld waarin veel van de patronen worden gebruikt die in dit artikel worden besproken. Er is ook een referentie-implementatie op GitHub.

Controlelijst voor betrouwbaarheid

Raadpleeg de volledige set aanbevelingen.

Controlelijst voor betrouwbaarheid