Afhandeling van tijdelijke fouten
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 de aard van de omgeving en de connectiviteit via internet inhoudt dat dergelijke fouten waarschijnlijk vaker zullen optreden. Tijdelijke fouten zijn onder meer tijdelijk verlies van de netwerkverbinding met onderdelen en services, tijdelijk ontbreken van een service, of time-outs die zich voordoen als een service bezet is. Deze fouten worden vaak zelf gecorrigeerd en als de actie na een geschikte vertraging wordt herhaald, is de kans groot dat deze slaagt.
Dit document bevat algemene richtlijnen voor het afhandelen van tijdelijke fouten. Zie Richtlijnen voor opnieuw proberen voor specifieke services voor informatie over het afhandelen van tijdelijke fouten bij het gebruik van Microsoft Azure-services.
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. In oplossingen die worden uitgevoerd op lokale on-premises infrastructuur, worden de prestaties en beschikbaarheid van de toepassing en de onderdelen ervan doorgaans onderhouden via dure en vaak onderbeschikt hardware redundantie en bevinden onderdelen en resources zich dicht bij elkaar. Hoewel deze aanpak een storing minder waarschijnlijk maakt, kan dit nog steeds leiden tot tijdelijke fouten en zelfs een storing door onvoorziene gebeurtenissen, zoals externe stroomvoorziening, netwerkproblemen of andere noodscenario's.
Cloudhosting, inclusief privécloudsystemen, kan een hogere algemene beschikbaarheid bieden door gebruik te maken van gedeelde resources, redundantie, automatische failover en dynamische toewijzing van resources op veel basisrekenknooppunten. De aard van deze omgevingen kan echter betekenen dat tijdelijke fouten vaker optreden. Hiervoor zijn diverse redenen:
Veel resources in een cloudomgeving worden gedeeld en toegang tot deze bronnen is onderworpen aan beperkingen ter bescherming van de resource. Voor sommige services worden verbindingen geweigerd als de belasting een bepaald niveau overstijgt of als er een maximum doorvoersnelheid wordt bereikt. Zodoende kunnen bestaande aanvragen worden verwerkt en kan de prestatie van de service voor alle gebruikers worden gehandhaafd. Dankzij deze beperkingen kan de kwaliteit van de service voor neighbors en andere tenants worden gehandhaafd met behulp van de gedeelde resource.
Cloudomgevingen zijn gebouwd met behulp van grote aantallen basishardware-eenheden. Ze leveren prestaties omdat de belasting over meerdere rekeneenheden en infrastructurele componenten wordt verdeeld. Ze zijn betrouwbaar omdat mislukte eenheden automatisch worden gerecycled of vervangen. Dit dynamische karakter is er de oorzaak van dat tijdelijke fouten en verbindingsfouten van tijd tot tijd kunnen optreden.
Er zijn vaak meer hardwareonderdelen, waaronder die in de netwerkinfrastructuur, zoals routers en load balancers, tussen de toepassing en de resources en services die erdoor worden gebruikt. Deze aanvullende infrastructuur kan soms extra verbindingslatentie en tijdelijke verbindingsfouten veroorzaken.
De netwerkomstandigheden tussen client en server kunnen variabel zijn, met name wanneer de communicatie via internet verloopt. Zelfs op on-premises locaties kan zware verkeersbelasting de communicatie vertragen en leiden tot onregelmatige verbindingsfouten.
Uitdagingen
Tijdelijke fouten kunnen een groot effect hebben op de waargenomen beschikbaarheid van een toepassing, zelfs als deze grondig is getest onder alle te verwachten omstandigheden. Om ervoor te zorgen dat cloudtoepassingen betrouwbaar werken, moeten ze kunnen omgaan met de volgende problemen:
De toepassing moet fouten kunnen detecteren zodra deze optreden, en bepalen of deze fouten van tijdelijke of meer langdurige aard zijn, of dat het blijvende fouten zijn. Verschillende resources geven vaak verschillende responses als er een fout optreed. Deze responses kunnen ook variëren als gevolg van de context van de bewerking, bijvoorbeeld de respons op een fout bij het lezen van opslag kan afwijken van die bij het schrijven naar opslag. Voor talloze resources en services zijn tijdelijke fouten vaak goed gedocumenteerd. Als dergelijke informatie niet beschikbaar is, kan het lastig zijn de aard van de fout te achterhalen en of deze al dan niet van tijdelijke aard is.
De toepassing moet bij een tijdelijke fout in staat zijn de bewerking te herhalen en het aantal malen dat de bewerking opnieuw wordt geprobeerd bij te houden.
De toepassing moet gebruikmaken van een passende strategie bij het opnieuw proberen. Voor deze strategie moet het aantal nieuwe pogingen worden opgegeven, de vertraging bij elke poging en de te nemen acties als een poging is mislukt. Het juiste aantal pogingen en de vertraging tussen de pogingen zijn vaak moeilijk vast te stellen en kunnen variëren als gevolg van het type resource en de operationele voorwaarden van de resource en de toepassing zelf.
Algemene richtlijnen
De volgende richtlijnen helpen u bij het ontwerpen van een geschikt mechanisme voor het afhandelen van tijdelijke fouten voor uw toepassingen:
Vaststellen of er een ingebouwd mechanisme is voor het uitvoeren van nieuwe pogingen:
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. Ook kunnen REST-interfaces voor services informatie opleveren waarmee kan worden bepaald of een nieuwe poging nuttig is en hoe lang moet worden gewacht tot de volgende poging.
Gebruik het ingebouwde mechanisme voor opnieuw proberen, indien beschikbaar, tenzij u specifieke en begrijpelijke vereisten hebt die een ander gedrag voor opnieuw proberen geschikter maken.
Vaststellen of de bewerking geschikt is voor een nieuwe poging:
U dient bewerkingen alleen opnieuw te proberen als de fouten tijdelijk zijn (gewoonlijk aangegeven door de aard van de fout) en dat de bewerking bij een nieuwe poging een kans van slagen heeft. Het heeft geen zin om bewerkingen opnieuw te proberen die wijzen op een ongeldige bewerking, zoals een database-update voor een item dat niet bestaat, of aanvragen naar een service of resource die een onresource heeft ondergaan met een fatale fout.
Voer over het algemeen alleen een nieuwe poging uit als de volledige impact ervan kan worden vastgesteld en als de omstandigheden duidelijk zijn en kunnen worden gevalideerd. Als dat niet het geval is, kunt u het implementeren van nieuwe pogingen beter overlaten aan de aanroepende code. Vergeet niet dat de fouten die worden geretourneerd door resources en services waarover u geen controle hebt, zich in de loop der tijd kunnen ontwikkelen en dat u mogelijk de detectielogica voor de tijdelijke fout opnieuw moet bekijken.
Als u services of onderdelen maakt, kunt u besluiten foutcodes en berichten te implementeren, zodat clients kunnen bepalen of mislukte bewerkingen opnieuw moeten worden geprobeerd. Geef in het bijzonder aan of de client de bewerking opnieuw moet proberen (wellicht door de waarde isTransient te retourneren) en stel een geschikte vertraging voor vóórdat een volgende poging wordt uitgevoerd. Als u een webservice bouwt, kunt u eventueel aangepaste fouten retourneren die binnen uw servicecontracten zijn gedefinieerd. Hoewel generieke clients deze mogelijk niet kunnen lezen, kunnen ze van nut zijn bij het bouwen van aangepaste clients.
Geschikt aantal nieuwe pogingen en interval vaststellen:
Het is cruciaal het aantal pogingen en het interval optimaal aan te passen aan het type use case. Als u onvoldoende nieuwe pogingen doet, kan de toepassing de bewerking niet voltooien en treedt er waarschijnlijk een fout op. Als u te veel nieuwe pogingen doet of een te kort interval gebruikt, kan de toepassing resources als threads, verbindingen en geheugen langere tijd vasthouden, met mogelijk negatieve gevolgen voor de status van de toepassing.
De juiste waarden voor het interval en het aantal pogingen hangen af van het type bewerking dat opnieuw wordt uitgevoerd. Als de bewerking bijvoorbeeld deel uitmaakt van een gebruikersinteractie, dient het interval kort te zijn en dienen slechts enkele nieuwe pogingen te worden gedaan om te voorkomen dat de gebruiker te lang op een respons moet wachten (waarbij verbindingen open worden gehouden en dus de beschikbaarheid voor anderen wordt verminderd). Als de bewerking deel uitmaakt van een langlopende of kritieke werkstroom, waarbij het annuleren en opnieuw starten van het proces duur of tijdrovend is, is het beter om langer te wachten tussen pogingen en het opnieuw te proberen.
Het vaststellen van het geschikte interval tussen pogingen is het moeilijkste deel bij het ontwerpen van een geslaagde strategie. Voor typische strategieën wordt gebruikgemaakt van de volgende intervaltypen:
Exponentieel uitschakelen. De toepassing wacht korte tijd voor de eerste poging wordt uitgevoerd. Vervolgens neemt het interval tussen de pogingen exponentieel toe. De nieuwe poging kan bijvoorbeeld na 3, 12, 30 seconden enzovoort worden uitgevoerd.
Incrementele intervallen. De toepassing wacht korte tijd voor de eerste poging wordt uitgevoerd. Vervolgens neemt het interval tussen de pogingen in stapjes toe. De nieuwe poging kan bijvoorbeeld na 3, 7, 13 seconden enzovoort worden uitgevoerd.
Regelmatige intervallen. Het interval tussen pogingen is telkens even lang. De bewerken wordt bijvoorbeeld elke drie seconden herhaalt.
Onmiddellijk opnieuw proberen. Soms is een tijdelijke fout kort, mogelijk als gevolg van een gebeurtenis, zoals een netwerkpakketbotsing of een piek in een hardwareonderdeel. In een dergelijk geval kan de bewerking het beste onmiddellijk opnieuw worden geprobeerd omdat deze kan slagen als de fout al is opgelost gedurende de tijd die het kost om de volgende aanvraag op te stellen en te verzenden. Er mag echter nooit meer dan één directe nieuwe poging zijn en u moet overschakelen naar alternatieve strategieën, zoals exponentieel terugvallen of terugvalacties, als de onmiddellijke nieuwe poging mislukt.
Randomisatie. Bij de hierboven genoemde strategieën voor nieuwe pogingen kan een randomisatie worden uitgevoerd om te voorkomen dat opvolgende nieuwe pogingen tegelijkertijd door meerdere instanties van de client worden verzonden. De ene instantie kan bijvoorbeeld de bewerking na 3, 11, 28 seconden, opnieuw uitvoeren, terwijl een ander exemplaar de bewerking na 4, 12 seconden, 26 seconden, en meer opnieuw kan uitvoeren. Randomisatie is een handige techniek die met andere strategieën kan worden gecombineerd.
Als algemene richtlijn geldt dat u exponentieel uitval gebruikt voor bewerkingen op de achtergrond, en onmiddellijke pogingen of pogingen met een regelmatig interval bij 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.
Houd ook rekening met de combinatie van alle factoren die bijdragen aan de maximale, totale time-out voor een bewerking waarvoor nieuwe pogingen worden gedaan. Deze factoren zijn onder meer de tijd voor het produceren van een respons bij een mislukte verbinding (gewoonlijk ingesteld door een time-outwaarde in de client), de vertraging tussen nieuwe pogingen en het aantal pogingen. Het totaal van al deze tijden kan leiden tot lange algemene bewerkingstijden, met name wanneer u een strategie voor exponentiële vertraging gebruikt waarbij het interval tussen nieuwe proberen snel toeneemt na elke fout. Als een proces moet voldoen aan een specifieke Service Level Agreement (SLA), moet de totale bewerkingstijd, inclusief alle time-outs en vertragingen, binnen de limieten liggen die zijn gedefinieerd in de SLA.
Te agressieve strategieën voor opnieuw proberen, die intervallen hebben die te kort zijn of nieuwe poging die te vaak voorkomen, kunnen een negatief effect hebben op de doelresource of service. Hierdoor kan namelijk worden voorkomen dat de resource of service zich hersteld van een overbelaste toestand en kunnen aanvragen blijvend worden geblokkeerd of geweigerd. Dit leidt tot een vicieuze cirkel waarbij telkens meer aanvragen naar de resource of service worden verzonden en de kans op herstel successievelijk wordt verminderd.
Houd rekening met de time-out van de bewerkingen bij het kiezen van het interval tussen nieuwe pogingen om te voorkomen dat een volgende poging onmiddellijk wordt uitgevoerd (bijvoorbeeld als de duur van de time-out gelijk is aan die van het interval). Bedenk ook of u de totale periode (de time-out plus de intervaltijden) beneden een bepaalde totale tijdsduur wilt houden. Bewerkingen met ongewoon korte of lange time-outs kunnen van invloed zijn op zowel de wachttijd als het aantal uit te voeren nieuwe pogingen.
Gebruik het uitzonderingstype en de eventuele bijbehorende gegevens of de foutcodes en -berichten die door de service worden geretourneerd om het interval en het aantal pogingen te optimaliseren. Sommige uitzonderingen of foutcodes (bijvoorbeeld HTTP-code 503 (service niet beschikbaar) met in de kop van de respons Opnieuw proberen na) kunnen een aanwijzing bevatten hoelang de fout kan duren, of dat de service is mislukt en niet op volgende pogingen reageert.
Antipatronen vermijden:
In veruit de meeste gevallen dient u implementaties te vermijden die gedupliceerde lagen met code voor nieuwe pogingen bevatten. Vermijd ontwerpen met trapsgewijze mechanismen voor nieuwe pogingen of die een nieuwe poging implementeren tijdens elke fase van een bewerking waarbij een hiërarchie van aanvragen bij betrokken zijn, tenzij u specifieke vereisten hebt die hierom vragen. 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. Als bijvoorbeeld de ene component een aanvraag doet bij een andere, die vervolgens toegang krijgt tot de doelservice en u drie nieuwe pogingen elk implementeert voor beide aanroepen, worden er in totaal negen nieuwe pogingen voor de service uitgevoerd. Veel services en resources implementeren een ingebouwd mechanisme voor opnieuw proberen en u dient te onderzoeken hoe u dit kunt uitschakelen of wijzigen als u nieuwe pogingen op een hoger niveau moet implementeren.
Implementeer nooit een mechanisme waarbij eindeloos nieuwe pogingen worden uitgevoerd. Hiermee wordt waarschijnlijk voorkomen dat de resource of service herstel van overbelasting en het zorgt ervoor dat beperkingen en geweigerde verbindingen langer aanhouden. Gebruik een eindig aantal nieuwe pogingen of implementeer een patroon (bijvoorbeeld Stroomonderbreker) zodat de service kan worden hersteld.
Voer een onmiddellijke nieuwe poging nooit vaker dan eenmaal uit.
Vermijd bij het openen van service en resources in Azure het gebruik van een regelmatig interval voor nieuwe pogingen als er een groot aantal nieuwe pogingen zijn. De optimale benadering in dit scenario is exponentiële terugval met de mogelijkheid de kringloop te kunnen onderbreken.
Vermijd dat meerdere instanties van dezelfde client of meerdere instanties van verschillende clients tegelijkertijd nieuwe pogingen verzenden. Als de kans hierop groot is, kunt u randomisatie in de intervallen voor nieuwe pogingen introduceren.
Strategie voor nieuwe pogingen en implementatie testen:
Zorg ervoor dat u uw strategie voor nieuwe pogingen en implementatie volledig test onder zoveel mogelijk omstandigheden, met name wanneer zowel de toepassing als de doelresources -of services waarvan gebruik wordt gemaakt extreem worden belast. Als u tijdens het testen het gedrag wilt controleren, kunt u:
Tijdelijke en niet-tijdelijke fouten in de service injecteren. Verzend bijvoorbeeld ongeldige aanvragen of voeg code toe waarmee testaanvragen worden gedetecteerd en waarop met verschillende typen fouten wordt gereageerd. Zie Fault Injection Testing with TestApi (Testen door foutinjectie met TestApi) en Introduction to TestApi – Part 5: Managed Code Fault Injection APIs (Inleiding tot TestApi – Deel 5: API's met foutinjectie met begeleide code) voor een voorbeeld met TestApi.
Maak een simulatie van de resource of service die een hoeveelheid fouten retourneert die het echte systeem kan retourneren. Zorg ervoor dat u elk fouttype probeert die de strategie met nieuwe pogingen kan detecteren.
Dwing tijdelijke fouten af door de service tijdelijk uit te stellen of te overbelasten als het een aangepaste service is die u hebt gemaakt en geïmplementeerd (natuurlijk moet u geen gedeelde resources of gedeelde services binnen Azure overbelasten).
Gebruik voor HTTP-API's de FiddlerCore-bibliotheek in uw geautomatiseerde tests om de uitkomst van HTTP-aanvragen te wijzigen door extra retourtijden toe te voegen of door de respons te wijzigen (zoals de HTTP-statuscode, headers, hoofdtekst of andere factoren). Dit maakt het deterministisch testen mogelijk van een subset van de foutvoorwaarden, zowel bij tijdelijke als overige fouten. Zie FiddlerCore voor meer informatie. Kijk in de broncode voor de Azure Storage SDK (Engelstalig) voor voorbeelden om de bibliotheek te gebruiken, met name de klasse HttpMangler.
Voer tests met hoge belastingfactor en gelijktijdige tests uit om ervoor te zorgen dat het mechanisme voor nieuwe pogingen onder deze omstandigheden correct werkt en geen negatief effect heeft op de bewerkingen van de client of dat er onderlinge beïnvloeding tussen aanvragen optreedt.
Configuraties voor beleid voor opnieuw proberen beheren:
Een beleid voor opnieuw proberen is een combinatie van alle elementen van uw strategie voor opnieuw proberen. Hiermee wordt het detectiemechanisme gedefinieerd dat bepaalt of een fout waarschijnlijk tijdelijk is, welk intervaltype moet worden gebruikt (bijvoorbeeld regelmatig, exponentieel verval en randomisatie). Het definieert tevens de werkelijke intervalwaarde(n) en het aantal nieuwe pogingen.
Nieuwe pogingen moeten op talloze plaatsen worden geïmplementeerd in zelfs de eenvoudigste toepassingen en in elke laag van meer complexe toepassingen. In plaats van hard-coding toe te passen op de elementen van elk beleid op meerdere locaties, kunt u gebruikmaken van een centraal punt voor het opslaan van alle beleidsregels. Sla waarden als het interval en het aantal nieuwe pogingen bijvoorbeeld op in toepassingsconfiguratiebestanden, lees deze bij runtime en bouw het beleid voor opnieuw proberen programmatisch op. Dit maakt het gemakkelijker 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 zodanig dat de waarden worden opgeslagen in plaats van dat telkens een configuratiebestand opnieuw moet worden gelezen. Zorg er ook voor dat geschikte standaardwaarden worden gebruikt als de waarden niet uit de configuratie kunnen worden gehaald.
In een Azure Cloud Services-toepassing kunt u besluiten de waarden die worden gebruikt bij het bouwen van het beleid voor opnieuw proberen, tijdens runtime op te slaan in het serviceconfiguratiebestand, zodat ze kunnen worden gewijzigd zonder dat de toepassing opnieuw hoeft te worden gestart.
Profiteer van ingebouwde of standaardstrategieën voor opnieuw proberen die in de gebruikte client-API's beschikbaar zijn, maar alleen als ze voor uw scenario geschikt zijn. Deze strategieën zijn doorgaans voor algemeen gebruik. In sommige scenario's zijn ze mogelijk voldoende, maar in andere bieden ze mogelijk niet het volledige spectrum aan opties die voor uw specifieke vereisten noodzakelijk zijn. U moet door middel van testen kennis nemen van de invloed van de instellingen op de toepassing om de meest geschikte waarden te bepalen.
Tijdelijke en niet-tijdelijke fouten in een logboek en bijhouden:
Neem als onderdeel van uw strategie voor opnieuw proberen het afhandelen van uitzonderingen en andere instrumentatie op, zodat wordt geregistreerd als er nieuwe pogingen worden uitgevoerd. Hoewel af en toe een tijdelijke fout en een nieuwe poging moeten worden verwacht en geen probleem aangeven, zijn regelmatige en toenemende aantallen nieuwe pogingen vaak een indicator van een probleem dat een fout kan veroorzaken of die momenteel de prestaties en beschikbaarheid van toepassingen vernedeert.
Registreer tijdelijke fouten als waarschuwingen in plaats van fouten, zodat de bewakingssystemen ze niet als toepassingsfouten ziet die een vals alarm kunnen activeren.
Overweeg een waarde in uw logboeken op te slaan die aangeeft of de nieuwe pogingen veroorzaakt zijn door beperkingen van de service of door andere typen fouten (bijvoorbeeld verbindingsfouten), zodat u onderscheid kunt maken tijdens de gegevensanalyse. 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.
U kunt ook besluiten de totale tijd voor bewerkingen waarbinnen een mechanisme voor opnieuw proberen besloten ligt, te meten en te registreren. Dit is een goede indicatie van het algehele effect van tijdelijke fouten op reactietijden van gebruikers, proceslatentie en de efficiëntie van use cases van toepassingen. Registreer ook het aantal nieuwe pogingen om begrip te krijgen van de factoren die een bijdrage leveren aan de reactietijd.
Overweeg het implementeren van een telemetrie- en bewakingssysteem dat een waarschuwing geeft als het aantal fouten en de frequentie ervan, het gemiddelde aantal nieuwe pogingen of de algemene duur voordat bewerkingen zijn voltooid, toenemen.
Bewerkingen beheren die voortdurend mislukken:
Er zijn omstandigheden waarbij de bewerking bij elke poging blijft mislukken en het is essentieel dat u erover nadenkt hoe u deze situatie afhandelt:
Hoewel een strategie van opnieuw proberen het maximum aantal keren definieert dat een bewerking moet worden herhaald, wordt hiermee niet voorkomen dat de bewerking opnieuw wordt herhaald met hetzelfde aantal nieuwe pogingen. Als bijvoorbeeld een orderverwerking mislukt door een onherstelbare fout waardoor de service er definitief uit ligt, kan de strategie voor opnieuw proberen een verbindingstime-out detecteren en deze als een tijdelijke fout beschouwen. De bewerking wordt een bepaald aantal keren opnieuw geprobeerd, waarna hiermee wordt gestopt. Als echter een andere klant een order plaatst wordt de bewerking nogmaals geprobeerd, hoewel deze elke keer zeker zal mislukken.
Om voortdurend nieuwe pogingen tegen te gaan van bewerkingen die voortdurend mislukken, kunt u het Stroomonderbrekerpatroon implementeren. Als het aantal fouten binnen een bepaalde periode de drempelwaarde overschrijdt, worden dankzij patroon aanvragen onmiddellijk als fouten naar de aanvrager teruggestuurd, zonder dat wordt geprobeerd de mislukte resource of service te openen.
De toepassing kan de service periodiek, met tussenpozen en met lange intervallen tussen aanvragen, testen om te detecteren wanneer deze beschikbaar komt. Een geschikt interval hangt af van het scenario, zoals de ernst van de bewerking en de aard van de service. Het interval kan liggen tussen enkele minuten en enkele uren. Op het moment dat de test slaagt, kan de toepassing de normale bewerkingen hervatten en aanvragen doorsturen naar de zojuist herstelde service.
Ondertussen kan ook worden teruggevallen op een andere instantie van de service (wellicht in een ander datacenter of een andere toepassing). Er kan ook een andere, soortgelijke service worden gebruikt die een compatibele (mogelijk eenvoudigere) functionaliteit biedt of er kunnen alternatieve bewerkingen worden uitgevoerd, in de hoop dat de service snel weer beschikbaar is. Het kan bijvoorbeeld handig zijn om aanvragen voor de service op te slaan in een wachtrij of gegevensarchief om ze later af te handelen. Wellicht bent u in staat de gebruiker door te sturen naar een alternatieve instantie van de toepassing, de prestaties van de toepassing te verlagen (en nog wel acceptabele functionaliteit te bieden) of alleen het bericht naar de gebruiker terug te sturen dat de toepassing momenteel niet beschikbaar is.
Andere overwegingen
Bij het bepalen van de waarden voor het aantal nieuwe pogingen en de intervallen voor opnieuw proberen voor een beleid, 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 lastig of kostbaar zijn om te compenseren voor de overige operationele stappen die al zijn voltooid voordat er een mislukt. In dat geval kan een zeer lang interval of een groot aantal nieuwe pogingen acceptabel zijn, zolang andere bewerkingen niet worden geblokkeerd doordat schaarse bronnen worden vastgehouden of vergrendeld.
Bedenk of het opnieuw proberen van dezelfde bewerking inconsistenties van gegevens kan veroorzaken. Als sommige onderdelen van een proces met meerdere stappen worden herhaald en de bewerkingen niet idempotent zijn, kan dit leiden tot inconsistentie. Als bijvoorbeeld een bewerking een waarde incrementeel verhoogt, kan er bij een nieuwe poging een ongeldig resultaat ontstaan. Het herhalen van een bewerking die een bericht naar de wachtrij stuur, kan tot een inconsistentie leiden in de berichtconsument als deze geen dubbele berichten kan detecteren. U kunt dit voorkomen door elke stap als een idempotente bewerking te ontwerpen. Zie Idempotentiepatronen voor meer informatie over idempotentie.
Kijk naar het bereik van de bewerkingen die opnieuw worden geprobeerd. Het kan bijvoorbeeld makkelijker zijn code voor nieuwe pogingen te implementeren op een niveau dat meerdere bewerkingen beslaat en ze allemaal tegelijk opnieuw te proberen als er een uitvalt. Dit kan echter tot indempotentieproblemen of onnodige terugdraaibewerkingen leiden.
Als u een bereik voor nieuwe pogingen kiest dat meerdere bewerkingen omvat, dient u rekening te houden met de totale latentie ervan bij het bepalen van de intervallen tussen pogingen, het bewaken van de benodigde tijdsduur en voordat waarschuwingen afgeeft bij fouten.
Bedenk hoe uw strategie voor opnieuw proberen van invloed kan zijn op neighbors en andere tenants in een gedeelde toepassing of 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. En omgekeerd kan uw toepassing ook worden beïnvloed door beleid voor opnieuw proberen dat door andere gebruikers van de resources en services wordt geïmplementeerd. Voor bedrijfskritische toepassingen kunt u besluiten premium services te gebruiken die niet worden gedeeld. Hiermee beschikt u over veel meer controle over de belasting en bijgevolg de beperkingen van deze resources en services. Het kan een rechtvaardiging zijn voor de bijkomende kosten.