Afhandeling van tijdelijke foutenTransient fault handling

Alle toepassingen die met externe services en bronnen communiceren moeten gevoelig zijn voor tijdelijke fouten.All applications that communicate with remote services and resources must be sensitive to transient faults. 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.This is especially the case for applications that run in the cloud, where the nature of the environment and connectivity over the Internet means these types of faults are likely to be encountered more often. 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.Transient faults include the momentary loss of network connectivity to components and services, the temporary unavailability of a service, or timeouts that arise when a service is busy. Deze fouten worden vaak zelf gecorrigeerd en als de actie wordt herhaald na een geschikte vertraging, zal deze waarschijnlijk slagen.These faults are often self-correcting, and if the action is repeated after a suitable delay it is likely to succeed.

Dit document bevat algemene richtlijnen voor het afhandelen van tijdelijke fouten.This document covers general guidance for transient fault handling. Zie Richtlijnen voor opnieuw proberen voor specifieke services voor informatie over het afhandelen van tijdelijke fouten bij het gebruik van Microsoft Azure-services.For information about handling transient faults when using Microsoft Azure services, see Azure service-specific retry guidelines.

Waarom doen zich tijdelijke fouten in de cloud voor?Why do transient faults occur in the cloud?

Tijdelijke fouten kunnen optreden in elke omgeving, op alle platforms en besturingssystemen, en in elke toepassing.Transient faults can occur in any environment, on any platform or operating system, and in any kind of application. In oplossingen die worden uitgevoerd op een lokale on-premises infra structuur, worden de prestaties en beschik baarheid van de toepassing en de bijbehorende onderdelen doorgaans gehandhaafd door dure en vaak gebruikte hardware-redundantie, en onderdelen en bronnen bevinden zich dicht bij elkaar.In solutions that run on local on-premises infrastructure, the performance and availability of the application and its components is typically maintained through expensive and often underused hardware redundancy, and components and resources are located close to each other. Hoewel deze benadering een storing ondervindt, kan het nog steeds leiden tot tijdelijke fouten en zelfs een onderbreking via onvoorziene gebeurtenissen, zoals externe voeding of netwerk problemen of andere nood scenario's.While this approach makes a failure less likely, it can still result in transient faults - and even an outage through unforeseen events such as external power supply or network issues, or other disaster scenarios.

Cloud Hosting, met inbegrip van particuliere cloud systemen, kan een hogere algehele Beschik baarheid bieden door gebruik te maken van gedeelde bronnen, redundantie, automatische failover en dynamische bron toewijzing in veel reken knooppunten.Cloud hosting, including private cloud systems, can offer higher overall availability by using shared resources, redundancy, automatic failover, and dynamic resource allocation across many commodity compute nodes. De aard van deze omgevingen kan echter betekenen dat tijdelijke fouten vaker optreden.However, the nature of these environments can mean that transient faults are more likely to occur. Hiervoor zijn diverse redenen:There are several reasons for this:

  • Veel resources in een cloudomgeving worden gedeeld en toegang tot deze bronnen is onderworpen aan beperkingen ter bescherming van de resource.Many resources in a cloud environment are shared, and access to these resources is subject to throttling in order to protect the 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.Some services will refuse connections when the load rises to a specific level, or a maximum throughput rate is reached, in order to allow processing of existing requests and to maintain performance of the service for all users. Dankzij deze beperkingen kan de kwaliteit van de service voor neighbors en andere tenants worden gehandhaafd met behulp van de gedeelde resource.Throttling helps to maintain the quality of service for neighbors and other tenants using the shared resource.

  • Cloudomgevingen zijn gebouwd met behulp van grote aantallen basishardware-eenheden.Cloud environments are built using vast numbers of commodity hardware units. 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.They deliver performance by dynamically distributing the load across multiple computing units and infrastructure components, and deliver reliability by automatically recycling or replacing failed units. Dit dynamische karakter is er de oorzaak van dat tijdelijke fouten en verbindingsfouten van tijd tot tijd kunnen optreden.This dynamic nature means that transient faults and temporary connection failures may occasionally occur.

  • 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.There are often more hardware components, including network infrastructure such as routers and load balancers, between the application and the resources and services it uses. Deze aanvullende infrastructuur kan soms extra verbindingslatentie en tijdelijke verbindingsfouten veroorzaken.This additional infrastructure can occasionally introduce additional connection latency and transient connection faults.

  • De netwerkomstandigheden tussen client en server kunnen variabel zijn, met name wanneer de communicatie via internet verloopt.Network conditions between the client and the server may be variable, especially when communication crosses the Internet. Zelfs bij on-premises locaties kan zware verkeers belasting de communicatie vertragen en kunnen er onregelmatige verbindings fouten optreden.Even in on-premises locations, heavy traffic loads may slow communication and cause intermittent connection failures.

UitdagingenChallenges

Tijdelijke fouten kunnen een enorme invloed hebben op de waargenomen Beschik baarheid van een toepassing, zelfs als deze grondig is getest onder alle te verwachten omstandigheden.Transient faults can have a huge effect on the perceived availability of an application, even if it has been thoroughly tested under all foreseeable circumstances. Om ervoor te zorgen dat cloudtoepassingen betrouwbaar werken, moeten ze kunnen omgaan met de volgende problemen:To ensure that cloud-hosted applications operate reliably, they must be able to respond to the following challenges:

  • 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.The application must be able to detect faults when they occur, and determine if these faults are likely to be transient, more long-lasting, or are terminal failures. 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.Different resources are likely to return different responses when a fault occurs, and these responses may also vary depending on the context of the operation; for example, the response for an error when reading from storage may be different from response for an error when writing to storage. Voor talloze resources en services zijn tijdelijke fouten vaak goed gedocumenteerd.Many resources and services have well-documented transient failure contracts. 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.However, where such information is not available, it may be difficult to discover the nature of the fault and whether it is likely to be transient.

  • 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.The application must be able to retry the operation if it determines that the fault is likely to be transient and keep track of the number of times the operation was retried.

  • De toepassing moet gebruikmaken van een passende strategie bij het opnieuw proberen.The application must use an appropriate strategy for the retries. 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.This strategy specifies the number of times it should retry, the delay between each attempt, and the actions to take after a failed attempt. 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.The appropriate number of attempts and the delay between each one are often difficult to determine, and vary based on the type of resource as well as the current operating conditions of the resource and the application itself.

Algemene richtlijnenGeneral guidelines

De volgende richt lijnen helpen u bij het ontwerpen van een geschikt mechanisme voor het afhandelen van tijdelijke fouten voor uw toepassingen:The following guidelines will help you to design a suitable transient fault handling mechanism for your applications:

  • Vaststellen of er een ingebouwd mechanisme is voor het uitvoeren van nieuwe pogingen:Determine if there is a built-in retry mechanism:

    • Veel services hebben een SDK of clientbibliotheek die een mechanisme voor het afhandelen van tijdelijke fouten bevat.Many services provide an SDK or client library that contains a transient fault handling mechanism. Het beleid voor opnieuw proberen is gewoonlijk aangepast aan de aard en de vereisten van de doelservice.The retry policy it uses is typically tailored to the nature and requirements of the target service. 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.Alternatively, REST interfaces for services may return information that is useful in determining whether a retry is appropriate, and how long to wait before the next retry attempt.

    • Gebruik het ingebouwde mechanisme voor opnieuw proberen wanneer dit beschikbaar is, tenzij u specifieke en duidelijke vereisten hebt die een afwijkend gedrag van nieuwe pogingen maken.Use the built-in retry mechanism where available, unless you have specific and well-understood requirements that make a different retry behavior more appropriate.

  • Vaststellen of de bewerking geschikt is voor een nieuwe poging:Determine if the operation is suitable for retrying:

    • 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.You should only retry operations where the faults are transient (typically indicated by the nature of the error), and if there is at least some likelihood that the operation will succeed when reattempted. Er is geen punt in het opnieuw proberen van bewerkingen die duiden op een ongeldige bewerking, zoals een Data Base-update voor een item dat niet bestaat of aanvragen voor een service of resource die een fatale fout hebben gehad.There is no point in reattempting operations that indicate an invalid operation such as a database update to an item that does not exist, or requests to a service or resource that has suffered a fatal error.

    • 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.In general, you should implement retries only where the full impact of this can be determined, and the conditions are well understood and can be validated. Als dat niet het geval is, kunt u het implementeren van nieuwe pogingen beter overlaten aan de aanroepende code.If not, leave it to the calling code to implement retries. 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.Remember that the errors returned from resources and services outside your control may evolve over time, and you may need to revisit your transient fault detection logic.

    • 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.When you create services or components, consider implementing error codes and messages that will help clients determine whether they should retry failed operations. 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.In particular, indicate if the client should retry the operation (perhaps by returning an isTransient value) and suggest a suitable delay before the next retry attempt. Als u een webservice bouwt, kunt u eventueel aangepaste fouten retourneren die binnen uw servicecontracten zijn gedefinieerd.If you build a web service, consider returning custom errors defined within your service contracts. Hoewel generieke clients deze mogelijk niet kunnen lezen, kunnen ze van nut zijn bij het bouwen van aangepaste clients.Even though generic clients may not be able to read these, they will be useful when building custom clients.

  • Geschikt aantal nieuwe pogingen en interval vaststellen:Determine an appropriate retry count and interval:

    • Het is cruciaal het aantal pogingen en het interval optimaal aan te passen aan het type use case.It is vital to optimize the retry count and the interval to the type of use case. Als u onvoldoende nieuwe pogingen doet, kan de toepassing de bewerking niet voltooien en treedt er waarschijnlijk een fout op.If you do not retry a sufficient number of times, the application will be unable to complete the operation and is likely to experience a failure. 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.If you retry too many times, or with too short an interval between tries, the application can potentially hold resources such as threads, connections, and memory for long periods, which will adversely affect the health of the application.

    • De juiste waarden voor het interval en het aantal pogingen hangen af van het type bewerking dat opnieuw wordt uitgevoerd.The appropriate values for the time interval and the number of retry attempts depend on the type of operation being attempted. 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).For example, if the operation is part of a user interaction, the interval should be short and only a few retries attempted to avoid making users wait for a response (which holds open connections and can reduce availability for other users). Als de bewerking deel uitmaakt van een langlopende of kritieke werk stroom, waar het annuleren en opnieuw starten van het proces kostbaar of tijdrovend is, is het van belang dat de pogingen langer worden gewacht en opnieuw proberen.If the operation is part of a long running or critical workflow, where canceling and restarting the process is expensive or time-consuming, it is appropriate to wait longer between attempts and retry more times.

    • Het vaststellen van het geschikte interval tussen pogingen is het moeilijkste deel bij het ontwerpen van een geslaagde strategie.Determining the appropriate intervals between retries is the most difficult part of designing a successful strategy. Voor typische strategieën wordt gebruikgemaakt van de volgende intervaltypen:Typical strategies use the following types of retry interval:

      • Exponentieel uitstel.Exponential back-off. De toepassing wacht korte tijd voor de eerste poging wordt uitgevoerd. Vervolgens neemt het interval tussen de pogingen exponentieel toe.The application waits a short time before the first retry, and then exponentially increasing times between each subsequent retry. De nieuwe poging kan bijvoorbeeld na 3, 12, 30 seconden enzovoort worden uitgevoerd.For example, it may retry the operation after 3 seconds, 12 seconds, 30 seconds, and so on.

      • Incrementele intervallen.Incremental intervals. De toepassing wacht korte tijd voor de eerste poging wordt uitgevoerd. Vervolgens neemt het interval tussen de pogingen in stapjes toe.The application waits a short time before the first retry, and then incrementally increasing times between each subsequent retry. De nieuwe poging kan bijvoorbeeld na 3, 7, 13 seconden enzovoort worden uitgevoerd.For example, it may retry the operation after 3 seconds, 7 seconds, 13 seconds, and so on.

      • Regelmatige intervallen.Regular intervals. Het interval tussen pogingen is telkens even lang.The application waits for the same period of time between each attempt. De bewerken wordt bijvoorbeeld elke drie seconden herhaalt.For example, it may retry the operation every 3 seconds.

      • Onmiddellijk opnieuw proberen.Immediate retry. Soms is een tijdelijke fout kort, mogelijk als gevolg van een gebeurtenis zoals een conflict met het netwerk pakket of een piek in een hardware-onderdeel.Sometimes a transient fault is brief, perhaps due to an event such as a network packet collision or a spike in a hardware component. 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.In this case, retrying the operation immediately is appropriate because it may succeed if the fault has cleared in the time it takes the application to assemble and send the next request. Er mogen echter nooit meer dan één onmiddellijke poging worden gedaan en u moet overschakelen naar alternatieve strategieën, zoals exponentiële back-ups of terugval acties, als de directe nieuwe poging mislukt.However, there should never be more than one immediate retry attempt, and you should switch to alternative strategies, such as exponential back-off or fallback actions, if the immediate retry fails.

      • Wille keurigheid.Randomization. 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.Any of the retry strategies listed above may include a randomization to prevent multiple instances of the client sending subsequent retry attempts at the same time. Zo kan één instantie de bewerking na 3 of 11 seconden, 28 seconden enzovoort opnieuw proberen, terwijl een andere instantie de bewerking na 4 of 12 seconden, 26 seconden, enzovoort opnieuw kan proberen.For example, one instance may retry the operation after 3 seconds, 11 seconds, 28 seconds, and so on, while another instance may retry the operation after 4 seconds, 12 seconds, 26 seconds, and so on. Randomisatie is een handige techniek die met andere strategieën kan worden gecombineerd.Randomization is a useful technique that may be combined with other strategies.

    • 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.As a general guideline, use an exponential back-off strategy for background operations, and immediate or regular interval retry strategies for interactive operations. 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.In both cases, you should choose the delay and the retry count so that the maximum latency for all retry attempts is within the required end-to-end latency requirement.

    • 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.Take into account the combination of all the factors that contribute to the overall maximum timeout for a retried operation. 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.These factors include the time taken for a failed connection to produce a response (typically set by a timeout value in the client) as well as the delay between retry attempts and the maximum number of retries. Het totaal van al deze tijden kan leiden tot lange algemene bewerkings tijden, met name bij het gebruik van een exponentiële vertragings strategie waarbij het interval tussen nieuwe pogingen snel na elke storing groeit.The total of all these times can result in long overall operation times, especially when using an exponential delay strategy where the interval between retries grows rapidly after each failure. Als een proces moet voldoen aan een specifieke service level agreement (SLA), moet de totale bewerkings tijd, inclusief alle time-outs en vertragingen, binnen de grenzen vallen die in de SLA zijn gedefinieerd.If a process must meet a specific service level agreement (SLA), the overall operation time, including all timeouts and delays, must be within the limits defined in the SLA.

    • De strategieën voor het opnieuw proberen van een nieuwe poging, met intervallen die te kort zijn of die te vaak worden herhaald, kunnen een nadelige invloed hebben op de doel resource of-service.Overly aggressive retry strategies, which have intervals that are too short or retries that are too frequent, can have an adverse effect on the target resource or 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.This may prevent the resource or service from recovering from its overloaded state, and it will continue to block or refuse requests. 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.This results in a vicious circle where more and more requests are sent to the resource or service, and consequently its ability to recover is further reduced.

    • 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).Take into account the timeout of the operations when choosing the retry intervals to avoid launching a subsequent attempt immediately (for example, if the timeout period is similar to the retry interval). Bedenk ook of u de totale periode (de time-out plus de intervaltijden) beneden een bepaalde totale tijdsduur wilt houden.Also consider if you need to keep the total possible period (the timeout plus the retry intervals) to below a specific total time. Bewerkingen met ongewoon korte of lange time-outs kunnen van invloed zijn op zowel de wachttijd als het aantal uit te voeren nieuwe pogingen.Operations that have unusually short or very long timeouts may influence how long to wait, and how often to retry the operation.

    • 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.Use the type of the exception and any data it contains, or the error codes and messages returned from the service, to optimize the interval and the number of retries. 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.For example, some exceptions or error codes (such as the HTTP code 503 Service Unavailable with a Retry-After header in the response) may indicate how long the error might last, or that the service has failed and will not respond to any subsequent attempt.

  • Antipatronen vermijden:Avoid anti-patterns:

    • In veruit de meeste gevallen dient u implementaties te vermijden die gedupliceerde lagen met code voor nieuwe pogingen bevatten.In the vast majority of cases, you should avoid implementations that include duplicated layers of retry code. 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.Avoid designs that include cascading retry mechanisms, or that implement retry at every stage of an operation that involves a hierarchy of requests, unless you have specific requirements that demand this. 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.In these exceptional circumstances, use policies that prevent excessive numbers of retries and delay periods, and make sure you understand the consequences. 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.For example, if one component makes a request to another, which then accesses the target service, and you implement retry with a count of three on both calls there will be nine retry attempts in total against the service. 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.Many services and resources implement a built-in retry mechanism and you should investigate how you can disable or modify this if you need to implement retries at a higher level.

    • Implementeer nooit een mechanisme waarbij eindeloos nieuwe pogingen worden uitgevoerd.Never implement an endless retry mechanism. Hiermee wordt waarschijnlijk voorkomen dat de resource of service herstel van overbelasting en het zorgt ervoor dat beperkingen en geweigerde verbindingen langer aanhouden.This is likely to prevent the resource or service recovering from overload situations, and cause throttling and refused connections to continue for a longer period. Gebruik een eindig aantal nieuwe pogingen of implementeer een patroon (bijvoorbeeld Stroomonderbreker) zodat de service kan worden hersteld.Use a finite number or retries, or implement a pattern such as Circuit Breaker to allow the service to recover.

    • Voer een onmiddellijke nieuwe poging nooit vaker dan eenmaal uit.Never perform an immediate retry more than once.

    • 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.Avoid using a regular retry interval, especially when you have a large number of retry attempts, when accessing services and resources in Azure. De optimale benadering in dit scenario is exponentiële terugval met de mogelijkheid de kringloop te kunnen onderbreken.The optimum approach is this scenario is an exponential back-off strategy with a circuit-breaking capability.

    • Vermijd dat meerdere instanties van dezelfde client of meerdere instanties van verschillende clients tegelijkertijd nieuwe pogingen verzenden.Prevent multiple instances of the same client, or multiple instances of different clients, from sending retries at the same times. Als de kans hierop groot is, kunt u randomisatie in de intervallen voor nieuwe pogingen introduceren.If this is likely to occur, introduce randomization into the retry intervals.

  • Strategie voor nieuwe pogingen en implementatie testen:Test your retry strategy and implementation:

    • 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.Ensure you fully test your retry strategy implementation under as wide a set of circumstances as possible, especially when both the application and the target resources or services it uses are under extreme load. Als u tijdens het testen het gedrag wilt controleren, kunt u:To check behavior during testing, you can:

      • Tijdelijke en niet-tijdelijke fouten in de service injecteren.Inject transient and nontransient faults into the service. Verzend bijvoorbeeld ongeldige aanvragen of voeg code toe waarmee testaanvragen worden gedetecteerd en waarop met verschillende typen fouten wordt gereageerd.For example, send invalid requests or add code that detects test requests and responds with different types of errors. 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.For an example using TestApi, see Fault Injection Testing with TestApi and Introduction to TestApi – Part 5: Managed Code Fault Injection APIs.

      • Maak een simulatie van de resource of service die een hoeveelheid fouten retourneert die het echte systeem kan retourneren.Create a mock of the resource or service that returns a range of errors that the real service may return. Zorg ervoor dat u elk fouttype probeert die de strategie met nieuwe pogingen kan detecteren.Ensure you cover all the types of error that your retry strategy is designed to detect.

      • Geforceerd tijdelijke fouten te ondervinden door de service tijdelijk uit te scha kelen of te overbelasten als het een aangepaste service is die u hebt gemaakt en geïmplementeerd (uiteraard moet u geen gedeelde resources of gedeelde services in azure proberen te overbelasten).Force transient errors to occur by temporarily disabling or overloading the service if it is a custom service that you created and deployed (of course, you should not attempt to overload any shared resources or shared services within Azure).

      • 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).For HTTP-based APIs, consider using the FiddlerCore library in your automated tests to change the outcome of HTTP requests, either by adding extra roundtrip times or by changing the response (such as the HTTP status code, headers, body, or other factors). Dit maakt het deterministisch testen mogelijk van een subset van de foutvoorwaarden, zowel bij tijdelijke als overige fouten.This enables deterministic testing of a subset of the failure conditions, whether transient faults or other types of failure. Zie FiddlerCore voor meer informatie.For more information, see FiddlerCore. Kijk in de broncode voor de Azure Storage SDK (Engelstalig) voor voorbeelden om de bibliotheek te gebruiken, met name de klasse HttpMangler.For examples of how to use the library, particularly the HttpMangler class, examine the source code for the Azure Storage SDK.

      • 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.Perform high load factor and concurrent tests to ensure that the retry mechanism and strategy works correctly under these conditions, and does not have an adverse effect on the operation of the client or cause cross-contamination between requests.

  • Configuraties voor beleid voor opnieuw proberen beheren:Manage retry policy configurations:

    • Een beleid voor opnieuw proberen is een combinatie van alle elementen van uw strategie voor opnieuw proberen.A retry policy is a combination of all of the elements of your retry strategy. 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.It defines the detection mechanism that determines whether a fault is likely to be transient, the type of interval to use (such as regular, exponential back-off, and randomization), the actual interval value(s), and the number of times to retry.

    • Nieuwe pogingen moeten op talloze plaatsen worden geïmplementeerd in zelfs de eenvoudigste toepassingen en in elke laag van meer complexe toepassingen.Retries must be implemented in many places within even the simplest application, and in every layer of more complex applications. 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.Rather than hard-coding the elements of each policy at multiple locations, consider using a central point for storing all the policies. 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.For example, store the values such as the interval and retry count in application configuration files, read them at runtime, and programmatically build the retry policies. Dit maakt het eenvoudiger om de instellingen te beheren en om de waarden aan te passen en te verfijnen om te reageren op veranderende vereisten en scenario's.This makes it easier to manage the settings, and to modify and fine-tune the values in order to respond to changing requirements and scenarios. 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.However, design the system to store the values rather than rereading a configuration file every time, and ensure suitable defaults are used if the values cannot be obtained from configuration.

    • 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.In an Azure Cloud Services application, consider storing the values that are used to build the retry policies at runtime in the service configuration file so that they can be changed without needing to restart the application.

    • 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.Take advantage of built-in or default retry strategies available in the client APIs you use, but only where they are appropriate for your scenario. Deze strategieën zijn doorgaans algemeen van toepassing.These strategies are typically general purpose. 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.In some scenarios they may be all that is required, but in other scenarios they may not offer the full range of options to suit your specific requirements. U moet door middel van testen kennis nemen van de invloed van de instellingen op de toepassing om de meest geschikte waarden te bepalen.You must understand how the settings will affect your application through testing to determine the most appropriate values.

  • Tijdelijke en niet-tijdelijke fouten vastleggen en bijhouden:Log and track transient and nontransient faults:

    • 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.As part of your retry strategy, include exception handling and other instrumentation that logs when retry attempts are made. Hoewel er een incidentele storing optreedt en er een nieuwe poging wordt gedaan, en dit geen probleem duidt, is een regel matig en toenemend aantal nieuwe pogingen vaak een indicatie van een probleem waardoor een fout kan optreden of waarmee de prestaties en beschik baarheid van de toepassing momenteel worden verminderd.While an occasional transient failure and retry are to be expected, and do not indicate a problem, regular and increasing numbers of retries are often an indicator of an issue that may cause a failure, or is currently degrading application performance and availability.

    • Registreer tijdelijke fouten als waarschuwingen in plaats van fouten, zodat de bewakingssystemen ze niet als toepassingsfouten ziet die een vals alarm kunnen activeren.Log transient faults as Warning entries rather than Error entries so that monitoring systems do not detect them as application errors that may trigger false alerts.

    • 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.Consider storing a value in your log entries that indicates if the retries were caused by throttling in the service, or by other types of faults such as connection failures, so that you can differentiate them during analysis of the data. 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.An increase in the number of throttling errors is often an indicator of a design flaw in the application or the need to switch to a premium service that offers dedicated hardware.

    • U kunt ook besluiten de totale tijd voor bewerkingen waarbinnen een mechanisme voor opnieuw proberen besloten ligt, te meten en te registreren.Consider measuring and logging the overall time taken for operations that include a retry mechanism. 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.This is a good indicator of the overall effect of transient faults on user response times, process latency, and the efficiency of the application use cases. Registreer ook het aantal nieuwe pogingen om begrip te krijgen van de factoren die een bijdrage leveren aan de reactietijd.Also log the number of retries occurred in order to understand the factors that contributed to the response time.

    • 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.Consider implementing a telemetry and monitoring system that can raise alerts when the number and rate of failures, the average number of retries, or the overall times taken for operations to succeed, is increasing.

  • Bewerkingen beheren die voortdurend mislukken:Manage operations that continually fail:

    • Er zijn omstandigheden waarbij de bewerking bij elke poging blijft mislukken en het is essentieel dat u erover nadenkt hoe u deze situatie afhandelt:There will be circumstances where the operation continues to fail at every attempt, and it is vital to consider how you will handle this situation:

      • 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.Although a retry strategy will define the maximum number of times that an operation should be retried, it does not prevent the application repeating the operation again, with the same number of retries. 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.For example, if an order processing service fails with a fatal error that puts it out of action permanently, the retry strategy may detect a connection timeout and consider it to be a transient fault. De bewerking wordt een bepaald aantal keren opnieuw geprobeerd, waarna hiermee wordt gestopt.The code will retry the operation a specified number of times and then give up. Als echter een andere klant een order plaatst wordt de bewerking nogmaals geprobeerd, hoewel deze elke keer zeker zal mislukken.However, when another customer places an order, the operation will be attempted again - even though it is sure to fail every time.

      • Om voortdurend nieuwe pogingen tegen te gaan van bewerkingen die voortdurend mislukken, kunt u het Stroomonderbrekerpatroon implementeren.To prevent continual retries for operations that continually fail, consider implementing the Circuit Breaker pattern. 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.In this pattern, if the number of failures within a specified time window exceeds the threshold, requests are returned to the caller immediately as errors, without attempting to access the failed resource or service.

      • De toepassing kan de service periodiek testen, op gezette tijden en met lange intervallen tussen aanvragen, om te detecteren wanneer deze beschikbaar wordt.The application can periodically test the service, on an intermittent basis and with long intervals between requests, to detect when it becomes available. 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.An appropriate interval will depend on the scenario, such as the criticality of the operation and the nature of the service, and might be anything between a few minutes and several hours. Op het moment dat de test slaagt, kan de toepassing de normale bewerkingen hervatten en aanvragen doorsturen naar de zojuist herstelde service.At the point where the test succeeds, the application can resume normal operations and pass requests to the newly recovered 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.In the meantime, it may be possible to fall back to another instance of the service (perhaps in a different datacenter or application), use a similar service that offers compatible (perhaps simpler) functionality, or perform some alternative operations in the hope that the service will become available soon. Het kan bijvoorbeeld handig zijn om aanvragen voor de service op te slaan in een wachtrij of gegevensarchief om ze later af te handelen.For example, it may be appropriate to store requests for the service in a queue or data store and replay them later. 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.Otherwise you might be able to redirect the user to an alternative instance of the application, degrade the performance of the application but still offer acceptable functionality, or just return a message to the user indicating that the application is not available at present.

  • Andere overwegingenOther considerations

    • Als u beslist over de waarden voor het aantal nieuwe pogingen en de intervallen voor opnieuw proberen voor een beleid, kunt u overwegen of de bewerking op de service of resource deel uitmaakt van een langlopende bewerking of een actie die uit meerdere stappen bestaat.When deciding on the values for the number of retries and the retry intervals for a policy, consider if the operation on the service or resource is part of a long-running or multistep operation. Het kan lastig of kostbaar zijn om te compenseren voor de overige operationele stappen die al zijn voltooid voordat er een mislukt.It may be difficult or expensive to compensate all the other operational steps that have already succeeded when one fails. 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.In this case, a very long interval and a large number of retries may be acceptable as long as it does not block other operations by holding or locking scarce resources.

    • Bedenk of het opnieuw proberen van dezelfde bewerking inconsistenties van gegevens kan veroorzaken.Consider if retrying the same operation may cause inconsistencies in data. Als sommige onderdelen van een proces met meerdere stappen worden herhaald en de bewerkingen niet idempotent zijn, kan dit leiden tot een inconsistentie.If some parts of a multistep process are repeated, and the operations are not idempotent, it may result in an inconsistency. Als bijvoorbeeld een bewerking een waarde incrementeel verhoogt, kan er bij een nieuwe poging een ongeldig resultaat ontstaan.For example, an operation that increments a value, if repeated, will produce an invalid result. 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.Repeating an operation that sends a message to a queue may cause an inconsistency in the message consumer if it cannot detect duplicate messages. U kunt dit voorkomen door elke stap als een idempotente bewerking te ontwerpen.To prevent this, ensure that you design each step as an idempotent operation. Zie idempotentie-patronenvoor meer informatie over idempotentie.For more information about idempotency, see Idempotency patterns.

    • Kijk naar het bereik van de bewerkingen die opnieuw worden geprobeerd.Consider the scope of the operations that will be retried. 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.For example, it may be easier to implement retry code at a level that encompasses several operations, and retry them all if one fails. Dit kan echter tot indempotentieproblemen of onnodige terugdraaibewerkingen leiden.However, doing this may result in idempotency issues or unnecessary rollback operations.

    • 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.If you choose a retry scope that encompasses several operations, take into account the total latency of all of them when determining the retry intervals, when monitoring the time taken, and before raising alerts for failures.

    • 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.Consider how your retry strategy may affect neighbors and other tenants in a shared application, or when using shared resources and services. 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.Aggressive retry policies can cause an increasing number of transient faults to occur for these other users and for applications that share the resources and services. 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.Likewise, your application may be affected by the retry policies implemented by other users of the resources and services. Voor bedrijfskritische toepassingen kunt u besluiten premium services te gebruiken die niet worden gedeeld.For mission-critical applications, you may decide to use premium services that are not shared. 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.This provides you with much more control over the load and consequent throttling of these resources and services, which can help to justify the additional cost.

Meer informatieMore information