Afhandeling van tijdelijke fouten

  • Artikel

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 wordt aangetroffen. Tijdelijke fouten zijn onder andere het tijdelijke verlies van netwerkconnectiviteit met onderdelen en services, de tijdelijke onbeschikbaarheid van een service en time-outs die optreden wanneer een service bezet is. Deze fouten zijn vaak zelf corrigerend, dus als de actie wordt herhaald na een geschikte vertraging, is het waarschijnlijk gelukt.

Dit artikel bevat algemene richtlijnen voor het afhandelen van tijdelijke fouten. Zie Richtlijnen voor opnieuw proberen voor Azure-services voor informatie over het afhandelen van tijdelijke fouten wanneer u Azure-services gebruikt.

Waarom doen zich tijdelijke fouten in de cloud voor?

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

Cloudhosting, inclusief privécloudsystemen, kan een hogere algemene beschikbaarheid bieden met behulp van gedeelde resources, redundantie, automatische failover en dynamische resourcetoewijzing op veel basis-rekenknooppunten. Vanwege de aard van cloudomgevingen zijn tijdelijke fouten echter waarschijnlijker. 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 toe te staan en de prestaties van de service voor alle gebruikers te behouden. Beperking helpt bij het onderhouden van de kwaliteit van de service voor buren en andere tenants die gebruikmaken van de gedeelde resource.

  • Cloudomgevingen maken gebruik van grote aantallen basishardware-eenheden. Ze leveren prestaties door de belasting dynamisch te verdelen over meerdere rekeneenheden en infrastructuuronderdelen. Ze leveren betrouwbaarheid door mislukte 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.

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

Uitdagingen

Tijdelijke fouten kunnen een groot effect hebben op de waargenomen beschikbaarheid van een toepassing, zelfs als deze onder alle voorzienbare omstandigheden grondig is getest. Om ervoor te zorgen dat toepassingen in de cloud 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 terminalfouten 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 leest uit de opslag, kan bijvoorbeeld verschillen van het antwoord op een fout wanneer deze naar de opslag schrijft. Veel resources en services hebben goed gedocumenteerde contracten voor tijdelijke fouten. Wanneer dergelijke informatie echter niet beschikbaar is, kan het lastig zijn om de aard van de fout te ontdekken en of deze waarschijnlijk tijdelijk is.

  • De toepassing moet de bewerking opnieuw kunnen uitvoeren als wordt vastgesteld dat de fout waarschijnlijk tijdelijk is. Het moet ook het aantal keren bijhouden dat de bewerking opnieuw wordt geprobeerd.

  • De toepassing moet een geschikte strategie gebruiken voor nieuwe pogingen. De strategie geeft het aantal keren aan dat de toepassing het 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 pogingen zijn vaak moeilijk te bepalen. De strategie is afhankelijk van het type resource en de huidige operationele omstandigheden van de resource en de toepassing.

Algemene richtlijnen

De volgende richtlijnen kunnen u helpen bij het ontwerpen van geschikte tijdelijke foutafhandelingsmechanismen 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 die u kan helpen bepalen of een nieuwe poging geschikt is en hoe lang moet worden gewacht voordat de volgende poging opnieuw wordt geprobeerd.

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

Bepalen of de bewerking geschikt is voor opnieuw proberen

  • Voer alleen bewerkingen voor opnieuw proberen uit als de fouten tijdelijk zijn (meestal aangegeven door de aard van de fout) en wanneer er ten minste een kans is dat de bewerking slaagt wanneer het opnieuw wordt geprobeerd. Er is geen punt bij het opnieuw proberen van bewerkingen die een ongeldige bewerking proberen uit te voeren, zoals een database-update naar een item dat niet bestaat of een aanvraag voor een service of resource die een fatale fout heeft geleden.

  • Implementeer in het algemeen alleen nieuwe pogingen wanneer u het volledige effect hiervan kunt bepalen en wanneer de voorwaarden goed worden begrepen en kunnen worden gevalideerd. Anders kunt u de aanroepende code nieuwe pogingen laten implementeren. Houd er rekening mee dat de fouten die worden geretourneerd door resources en services buiten uw controle, zich na verloop van tijd kunnen ontwikkelen en dat u mogelijk uw 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 uitvoeren (mogelijk door een isTransient-waarde te retourneren) en stel een geschikte vertraging voor voor de volgende poging. Als u een webservice bouwt, kunt u aangepaste fouten retourneren die zijn gedefinieerd in uw servicecontracten. Hoewel algemene clients deze fouten mogelijk niet kunnen lezen, zijn ze handig bij het maken van aangepaste clients.

Bepaal het juiste aantal nieuwe pogingen en het juiste interval

  • Optimaliseer het aantal nieuwe pogingen en het interval naar het type use case. Als u niet genoeg nieuwe pogingen uitvoert, kan de toepassing de bewerking niet voltooien en mislukt dit waarschijnlijk. Als u het te vaak opnieuw probeert of met een te kort interval tussen pogingen, kan de toepassing resources bevatten, zoals threads, verbindingen en geheugen voor lange perioden, wat de status van de toepassing nadelig beïnvloedt.

  • Pas waarden aan voor het tijdsinterval en het aantal nieuwe pogingen tot het type bewerking. Als de bewerking bijvoorbeeld deel uitmaakt van een gebruikersinteractie, moet het interval kort zijn en moeten er slechts enkele nieuwe pogingen worden gedaan. Door deze methode te gebruiken, kunt u voorkomen dat gebruikers wachten op een reactie, die open verbindingen bevat en de beschikbaarheid voor andere gebruikers kan verminderen. Als de bewerking deel uitmaakt van een langlopende of kritieke werkstroom, waarbij het proces wordt geannuleerd en opnieuw wordt gestart, is het handig om langer te wachten tussen pogingen en meer pogingen.

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

    • Exponentieel uitstel. De toepassing wacht even voordat de eerste nieuwe poging opnieuw wordt uitgevoerd en verhoogt vervolgens de tijd tussen elke volgende nieuwe poging exponentieel. De bewerking kan bijvoorbeeld na 3 seconden, 12 seconden, 30 seconden enzovoort opnieuw worden uitgevoerd.

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

    • Regelmatige intervallen. Het interval tussen pogingen is telkens even lang. De bewerking kan bijvoorbeeld elke 3 seconden opnieuw worden uitgevoerd.

    • 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 opnieuw proberen van de bewerking onmiddellijk geschikt, omdat het kan slagen als de fout wordt gewist in de tijd dat de toepassing nodig is om de volgende aanvraag samen te stellen en te verzenden. Er mag echter nooit meer dan één onmiddellijke nieuwe poging worden uitgevoerd. U moet overschakelen naar alternatieve strategieën, zoals exponentieel uitstel of terugvalacties, als de onmiddellijke nieuwe poging mislukt.

    • Randomisatie. Een van de eerder vermelde strategieën voor opnieuw proberen kan een randomisatie bevatten om te voorkomen dat meerdere exemplaren van de client volgende nieuwe pogingen tegelijkertijd verzenden. Een exemplaar kan bijvoorbeeld de bewerking na 3 seconden, 11 seconden, 28 seconden enzovoort opnieuw uitvoeren, terwijl een ander exemplaar de bewerking na 4 seconden, 12 seconden, 26 seconden enzovoort opnieuw kan proberen. Randomisatie is een handige techniek die kan worden gecombineerd met andere strategieën.

  • Als algemene richtlijn gebruikt u een exponentieel uitstelstrategie voor achtergrondbewerkingen en gebruikt u onmiddellijke of regelmatige intervalstrategieën 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.

  • Neem rekening met de combinatie van alle factoren die bijdragen aan de totale maximale time-out voor een nieuwe poging. Deze factoren omvatten de tijd die nodig is voor een mislukte verbinding om een antwoord te produceren (meestal ingesteld door 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 exponentiële vertragingsstrategie 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 operationele tijd, 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 voorkomen. Ze kunnen een nadelig effect hebben op de doelresource of -service. Deze strategieën kunnen verhinderen dat de resource of service wordt hersteld van de overbelaste status en dat aanvragen blijven worden geblokkeerd of geweigerd. Dit scenario resulteert in een vicieuze cirkel, waarbij steeds meer aanvragen naar de resource of service worden verzonden. Het vermogen om te herstellen wordt dus verder verminderd.

  • Houd rekening met de time-out van de bewerkingen wanneer u intervallen voor opnieuw proberen 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 specifieke 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 de gegevens die deze bevatten, of de foutcodes en berichten die worden geretourneerd door de service, 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 header Opnieuw proberen na 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.

Antipatronen voorkomen

  • Vermijd in de meeste gevallen implementaties die dubbele lagen van code voor opnieuw proberen bevatten. Vermijd ontwerpen die trapsgewijze mechanismen voor opnieuw proberen bevatten of die nieuwe pogingen implementeren in elke fase van een bewerking waarbij een hiërarchie van aanvragen is betrokken, tenzij u specifieke vereisten hebt die dit vereisen. 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 één onderdeel een aanvraag naar een ander onderdeel doet, dat vervolgens toegang krijgt tot de doelservice. Als u nieuwe pogingen implementeert met een telling van drie voor 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 herstelt uit overbelastingssituaties en dat verbindingen worden beperkt en geweigerd om langer door te gaan. 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 hebt tot services en resources in Azure, met name wanneer u een groot aantal nieuwe pogingen hebt. De beste aanpak in dit scenario is een exponentiële back-off-strategie met een circuitonderbrekingsmogelijkheid.

  • Voorkomen dat meerdere exemplaren van dezelfde client of meerdere exemplaren van verschillende clients tegelijkertijd nieuwe pogingen verzenden. Als dit scenario waarschijnlijk plaatsvindt, introduceert u randomisatie in de intervallen voor opnieuw proberen.

Uw strategie en implementatie voor opnieuw proberen testen

  • Test uw strategie voor opnieuw proberen volledig onder zo breed mogelijke omstandigheden, met name wanneer zowel de toepassing als de doelresources of -services die worden gebruikt, onder extreme belasting vallen. 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. Zie Foutinjectietests met TestApi en Inleiding tot TestApi - deel 5: Api's voor foutinjectie van beheerde code voor voorbeelden die gebruikmaken van TestApi.

    • Maak een mock-up van de resource of service die een reeks fouten retourneert die de echte service kan retourneren. Bedek alle typen fouten die uw strategie voor opnieuw proberen is ontworpen om te detecteren.

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

    • Voor HTTP-API's kunt u overwegen om een bibliotheek in uw geautomatiseerde tests te gebruiken om het resultaat van HTTP-aanvragen te wijzigen, door extra retourtijden toe te voegen of door het antwoord te wijzigen (zoals de HTTP-statuscode, headers, hoofdteksten of andere factoren). Hiermee kunt u deterministisch testen van een subset van de foutvoorwaarden, voor tijdelijke fouten en andere soorten fouten.

    • Voer een hoge belastingfactor 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.

Beleidsconfiguraties 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 regelmatig, exponentieel uitstel 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 hard 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 programmatisch het beleid voor opnieuw proberen. 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.

  • In een Azure Cloud Services-toepassing kunt u overwegen de waarden op te slaan die worden gebruikt om het beleid voor opnieuw proberen tijdens runtime te bouwen in het serviceconfiguratiebestand, zodat u deze kunt wijzigen zonder de toepassing opnieuw op 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 aan uw specifieke vereisten voldoen. Als u de meest geschikte waarden wilt bepalen, moet u testen om te begrijpen hoe de instellingen van invloed zijn op uw toepassing.

Tijdelijke en niet-tijdelijke fouten vastleggen en bijhouden

  • Neem als onderdeel van uw strategie voor opnieuw proberen uitzonderingsafhandeling en andere instrumentatie op waarmee nieuwe pogingen worden geregistreerd. Een incidentele tijdelijke fout en nieuwe poging 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 die de prestaties en beschikbaarheid van toepassingen verslechtert.

  • Tijdelijke fouten vastleggen als waarschuwingsvermeldingen in plaats van als foutvermeldingen, zodat bewakingssystemen deze niet detecteren als toepassingsfouten die valse waarschuwingen kunnen activeren.

  • U kunt een waarde opslaan in uw logboekvermeldingen die aangeven of nieuwe pogingen worden veroorzaakt door beperking in de service of door andere typen 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 reactietijden van gebruikers, proceslatentie en de efficiëntie van toepassingsgebruiksscenario's. Registreer ook het aantal nieuwe pogingen dat zich voordoet, zodat u inzicht krijgt in de factoren die bijdragen aan de reactietijd.

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

Bewerkingen beheren die voortdurend mislukken

  • Denk na over hoe u bewerkingen afhandelt die bij elke poging blijven mislukken. Situaties zoals deze zijn onvermijdelijk.

    • Hoewel een strategie voor opnieuw proberen het maximum aantal keren definieert dat een bewerking opnieuw moet worden geprobeerd, wordt niet voorkomen 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 wordt gesteld, kan de strategie voor opnieuw proberen een time-out voor de verbinding detecteren en overwegen deze een tijdelijke fout te zijn. De code probeert de bewerking een opgegeven aantal keren opnieuw uit te voeren en geeft vervolgens op. Wanneer een andere klant echter een order plaatst, wordt de bewerking opnieuw geprobeerd, ook al mislukt deze elke keer.

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

    • De toepassing kan de service periodiek testen, op onregelmatige basis 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. Het kan iets zijn tussen een paar minuten en enkele uren. 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 misschien terugvallen op een ander exemplaar van de service (misschien in een ander datacenter of 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 is. Het kan bijvoorbeeld handig zijn om aanvragen voor de service op te slaan in een wachtrij of gegevensarchief en ze later opnieuw te proberen. Of u kunt de gebruiker omleiden naar een alternatief exemplaar van de toepassing, de prestaties van de toepassing verminderen, maar toch 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 voor de service of resource deel uitmaakt van een langlopende of multistep-bewerking. Het kan lastig of duur zijn om alle andere operationele stappen te compenseren die al zijn geslaagd wanneer één mislukt. In dit geval kunnen een zeer lang interval en een groot aantal nieuwe pogingen acceptabel zijn zolang die strategie andere bewerkingen niet blokkeert door schaarse resources vast te houden of te vergrendelen.

  • Overweeg of het opnieuw proberen van dezelfde bewerking inconsistenties in gegevens kan veroorzaken. Als sommige delen van een proces met meerdere stappen worden herhaald en de bewerkingen niet idempotent zijn, kunnen inconsistenties optreden. Als een bewerking waarmee een waarde wordt verhoogd, bijvoorbeeld wordt herhaald, wordt er een ongeldig resultaat gegenereerd. Als u een bewerking herhaalt waarmee een bericht naar een wachtrij wordt verzonden, kan dit leiden tot inconsistentie in de berichtconsumer als de consument geen dubbele berichten kan detecteren. Als u deze scenario's wilt 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 meerdere bewerkingen omvat en ze allemaal opnieuw proberen 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 opnieuw proberen bepaalt, wanneer u de verstreken tijden van de bewerking bewaakt en voordat u waarschuwingen voor fouten genereert.

  • Overweeg 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 door andere gebruikers van de resources en services is geïmplementeerd. Voor bedrijfskritieke toepassingen wilt u mogelijk Premium-services gebruiken die niet worden gedeeld. Dit biedt u meer controle over de belasting en consequente beperking van deze resources en services, wat kan helpen om de extra kosten te rechtvaardigen.