Hvad betyder Exponential backoff?
Exponential backoff er en strategi for genforsøg. Efter en midlertidig fejl venter klienten, og ved nye fejl bliver pausen større. En illustrativ sekvens kan være ét, to, fire og otte sekunder, typisk med et loft og tilfældig variation.
Formålet er at give den eksterne tjeneste tid til at komme sig og undgå, at mange klienter rammer den samtidig. Strategien løser ikke enhver fejl. Et ugyldigt kundenummer eller manglende tilladelse bliver normalt ikke korrekt af at vente længere.
Aftal hvilke fejl der må genforsøges
Klassificér fejl efter den konkrete tjenestes dokumentation. Midlertidig utilgængelighed og visse kapacitetsfejl kan være relevante kandidater. Valideringsfejl kræver ofte ændret input, mens adgangsfejl kan kræve en ny forbindelse eller menneskelig afklaring. Respektér en dokumenteret Retry-After-anvisning, når tjenesten giver den.
Sæt både et maksimum for pausen og et samlet budget for tid eller antal forsøg. Tilføj tilfældig variation, ofte kaldet jitter, så mange opgaver ikke genforsøger på præcis samme tidspunkt. En kø kan hjælpe med at holde arbejdet, mens tjenesten er presset.
Genforsøg må ikke gentage en ukendt virkning
Et tidsudløb fortæller ikke sikkert, at serveren ikke udførte handlingen. Brug derfor idempotens eller en anden verificerbar mekanisme ved ændringer. Undgå samtidig genforsøg i mange lag, hvor browser, backend og SDK alle gentager samme fejl. Den samlede belastning kan blive langt større end forventet. Log forsøg og endelig status, så driftsteamet kan se forskel på en kortvarig forstyrrelse og en vedvarende fejl, der kræver handling.
Et eksempel fra praksis
En dokumentintegration afleverer validerede data til et ERP-API. Ved en midlertidig kapacitetsfejl venter den gradvist længere og bruger samme identifikation for den logiske aflevering. Efter det aftalte budget flyttes sagen til en synlig fejlkø. Et testmiljø svarer først med midlertidige fejl og derefter normalt. Testen kontrollerer, at pauserne følger politikken, at der kun oprettes én post, og at en permanent valideringsfejl ikke genforsøges blindt.
Typiske faldgruber
- At bruge backoff på fejl, som kræver ændret input eller rettighed.
- At genforsøge en mulig gennemført oprettelse med en ny identifikation.
- At lade flere softwarelag multiplicere antallet af forsøg.
Det skal I afklare
- Definér genforsøgbare fejl ud fra tjenestens kontrakt.
- Brug loft, samlet budget og passende tilfældig variation.
- Test idempotens og en tydelig slutstatus ved udtømt budget.
Spørgsmål og svar
Skal pausen altid fordobles?
Nej. Fordobling er et almindeligt eksempel, men faktoren og pausen bør følge systemets behov og udbyderens anbefaling. Det centrale er kontrolleret ventetid frem for hurtige, ubegrænsede gentagelser.
Er backoff det samme som rate limiting?
Nej. Rate limiting begrænser trafik. Backoff beskriver, hvordan klienten reagerer på bestemte fejl. De kan supplere hinanden, men har forskellige roller.
Kilder og videre læsning
De tekniske begreber bygger på nedenstående kilder. Eksemplerne er illustrative og viser, hvordan I kan arbejde med emnet.
- Microsoft: Retry pattern ↗Genforsøg ved midlertidige fejl og hensyn til belastning.
- Google Cloud: Retry strategy ↗Eksponentiel ventetid, tilfældig variation og idempotens.