Mønstre for API-ratebegrensning og skalerbarhet · leksjon

Idempotens og mekanismer for nye forsøk

Utform idempotente API-operasjoner og implementer intelligente mekanismer for nye forsøk, slik at midlertidige feil håndteres på en kontrollert måte uten bivirkninger.

Leksjon 2 av 412 trinn

Idempotens og mekanismer for nye forsøk er en gratis leksjon i Mønstre for API-ratebegrensning og skalerbarhet på CoddyKit. Dette er leksjon 2 av 4. Du kan lese hele leksjonen gratis nedenfor – og deretter øve praktisk i nettleseren med en innebygd kodeeditor og en AI-veileder som er tilgjengelig døgnet rundt. Den er en del av læringsløpet i Mønstre for API-ratebegrensning og skalerbarhet, og fremdriften din synkroniseres mellom nettet og CoddyKit-appen. Kurset i Mønstre for API-ratebegrensning og skalerbarhet inneholder totalt 4 leksjoner.

Hva er idempotens?

I distribuerte systemer kan operasjoner noen ganger mislykkes eller bli avbrutt. Idempotens er en egenskap ved en operasjon som innebærer at flere utføringer gir samme resultat som én utføring.

Tenk på det som å trykke gjentatte ganger på en «på/av»-knapp. Hvis den virkelig er idempotent, endrer det første trykket tilstanden, mens etterfølgende trykk (uten et mellomliggende «av») ikke endrer den ytterligere. Sluttilstanden forblir den samme.

Hvorfor idempotens er viktig

Idempotens er avgjørende for å bygge robuste og pålitelige API-er, særlig ved nettverksproblemer eller midlertidige serverfeil.

  • Forhindrer doble handlinger: Hvis en forespørsel mislykkes underveis og klienten prøver på nytt, sikrer idempotens at operasjonen ikke utføres to ganger.
  • Sikrer datakonsistens: Hindrer at det opprettes doble poster eller utføres feilaktige tilstandsendringer.
  • Støtter nye forsøk: Det er et grunnleggende prinsipp som gjør det mulig for klienter å prøve forespørsler på nytt uten utilsiktede bieffekter.

Idempotent kontra ikke-idempotent

La oss se på vanlige HTTP-metoder og idempotensen deres:

  • GET: Alltid idempotent. Det å hente data flere ganger endrer dem ikke.
  • PUT: Idempotent. Oppdatering av en hel ressurs flere ganger gir samme sluttilstand.
  • DELETE: Idempotent. Sletting av en ressurs flere ganger har samme effekt som å slette den én gang (den forblir slettet).
  • POST: Vanligvis ikke idempotent. Oppretting av en ny ressurs flere ganger oppretter vanligvis flere nye ressurser.

Det avgjørende er resultatet, ikke selve handlingen.

Implementering av idempotensnøkler

For ikke-idempotente operasjoner som POST (for eksempel oppretting av en ordre eller behandling av en betaling) kan vi innføre en idempotensnøkkel.

Dette er en unik identifikator (ofte en UUID) som klienten genererer og sender med forespørselen. Serveren bruker deretter denne nøkkelen til å oppdage og ignorere doble forespørsler innenfor et bestemt tidsrom.

Idempotenskontroll på serversiden

Her ser vi konseptuelt på hvordan en server kan håndtere en idempotensnøkkel. Serveren kontrollerer om nøkkelen allerede er behandlet for den aktuelle operasjonen.

import java.util.Map;
import java.util.concurrent.ConcurrentHashMap;

public class PaymentProcessor {

    private Map<String, Boolean> processedKeys = new ConcurrentHashMap<>();

    public String processPayment(String idempotencyKey, double amount) {
        if (processedKeys.containsKey(idempotencyKey)) {
            System.out.println("Duplicate request for key: " + idempotencyKey + ". Returning previous result.");
            return "Payment already processed for key " + idempotencyKey;
        }

        // Simulate payment processing
        System.out.println("Processing payment of $" + amount + " with key: " + idempotencyKey);
        try {
            Thread.sleep(100); // Simulate work
        } catch (InterruptedException e) {
            Thread.currentThread().interrupt();
        }

        processedKeys.put(idempotencyKey, true);
        return "Payment successful for key " + idempotencyKey;
    }

    public static void main(String[] args) {
        PaymentProcessor processor = new PaymentProcessor();

        // First attempt with a key
        System.out.println(processor.processPayment("uuid-123", 100.00));

        // Retry with the same key (should be ignored)
        System.out.println(processor.processPayment("uuid-123", 100.00));

        // New request with a different key
        System.out.println(processor.processPayment("uuid-456", 50.00));
    }
}

Introduksjon til nye forsøk

Selv med idempotente operasjoner kan forespørsler fortsatt mislykkes på grunn av midlertidige problemer som tidsavbrudd i nettverket, overbelastning av serveren eller korte tjenesteavbrudd. Det er her mekanismer for nye forsøk kommer inn.

En mekanisme for nye forsøk prøver automatisk å utføre en mislykket operasjon på nytt etter en kort forsinkelse. Målet er å overvinne forbigående (midlertidige) feil og gjøre API-kall mer pålitelige.

Grunnleggende logikk for nye forsøk

Den enkleste mekanismen for nye forsøk innebærer et fast antall nye forsøk med en konstant forsinkelse mellom hvert forsøk. Selv om dette er enkelt, kan det noen ganger overbelaste en tjeneste som er i ferd med å hente seg inn, dersom mange klienter prøver på nytt samtidig.

public class SimpleRetry {

    public static void makeApiCall() {
        int maxRetries = 3;
        int retryCount = 0;
        long delayMillis = 1000; // 1 second

        while (retryCount < maxRetries) {
            try {
                System.out.println("Attempt " + (retryCount + 1) + ": Making API call...");
                // Simulate an API call that might fail
                if (Math.random() > 0.6) { // 40% chance of success
                    System.out.println("API call successful!");
                    return; // Exit if successful
                } else {
                    throw new RuntimeException("Simulated API failure.");
                }
            } catch (RuntimeException e) {
                System.out.println("API call failed: " + e.getMessage());
                retryCount++;
                if (retryCount < maxRetries) {
                    try {
                        System.out.println("Retrying in " + delayMillis + "ms...");
                        Thread.sleep(delayMillis);
                    } catch (InterruptedException ie) {
                        Thread.currentThread().interrupt();
                        System.out.println("Retry interrupted.");
                        break;
                    }
                }
            }
        }
        System.out.println("All retry attempts failed.");
    }

    public static void main(String[] args) {
        makeApiCall();
    }
}

Eksponentiell tilbakeventing

For å unngå å overbelaste tjenester og gi dem mer tid til å hente seg inn er eksponentiell tilbakeventing en bedre strategi. Den øker gradvis forsinkelsen mellom nye forsøk.

Forsinkelsene kan for eksempel være 1s, 2s, 4s, 8s og så videre. Dette reduserer belastningen på en tjeneste som har problemer, og sprer nye forsøk utover i tid.

Tilbakeventing med jitter

Selv med eksponentiell tilbakeventing kan mange klienter som feiler og prøver på nytt med nøyaktig de samme eksponentielle intervallene, fortsatt skape et «tordnende flokk»-problem, der alle treffer tjenesten samtidig.

Jitter legger til en tilfeldig komponent i forsinkelsen. Dette bidrar til å jevne ut de nye forsøkene, fordele dem jevnere og forhindre synkroniserte trafikkbølger.

import java.util.Random;

public class ExponentialBackoffRetry {

    private static final Random random = new Random();

    public static void makeApiCallWithBackoff() {
        int maxRetries = 5;
        long baseDelay = 500; // milliseconds
        long maxDelay = 16000; // cap the delay at 16 seconds

        for (int retryCount = 0; retryCount < maxRetries; retryCount++) {
            try {
                System.out.println("Attempt " + (retryCount + 1) + ": Making API call...");
                // Simulate an API call that might fail
                if (Math.random() > 0.7) { // 30% chance of success
                    System.out.println("API call successful!");
                    return; // Exit if successful
                } else {
                    throw new RuntimeException("Simulated API failure.");
                }
            } catch (RuntimeException e) {
                System.out.println("API call failed: " + e.getMessage());
                if (retryCount < maxRetries - 1) {
                    long delay = baseDelay * (long) Math.pow(2, retryCount);
                    delay = Math.min(delay, maxDelay);
                    // Add jitter: random value between 0 and delay
                    long jitteredDelay = random.nextInt((int) delay);

                    try {
                        System.out.println("Retrying in " + jitteredDelay + "ms (base: " + delay + ")...");
                        Thread.sleep(jitteredDelay);
                    } catch (InterruptedException ie) {
                        Thread.currentThread().interrupt();
                        System.out.println("Retry interrupted.");
                        break;
                    }
                }
            }
        }
        System.out.println("All retry attempts failed after " + maxRetries + " retries.");
    }

    public static void main(String[] args) {
        makeApiCallWithBackoff();
    }
}

Idempotens og nye forsøk sammen

Idempotens og mekanismer for nye forsøk er en kraftig kombinasjon for å bygge robuste distribuerte systemer.

  • Nye forsøk håndterer forbigående nettverks- eller tjenestefeil og øker sannsynligheten for at en operasjon lykkes.
  • Idempotens sikrer at det ikke oppstår skadelige dupliserte sideeffekter dersom et nytt forsøk gjøres for en operasjon som faktisk lyktes, men klienten ikke mottok bekreftelsen.

Sammen gjør de det mulig for klienter å utføre API-kall med trygghet, fordi midlertidige problemer ikke fører til datakorrupsjon eller feilaktige tilstander.

Test forståelsen din

Hvilke av følgende påstander om idempotens og mekanismer for nye forsøk er SANNE?

Oppsummering: Robuste API-er

I denne leksjonen utforsket vi to viktige konsepter for å bygge svært skalerbare og robuste API-er:

  • Idempotens: Operasjoner som gir samme resultat enten de utføres én eller flere ganger, noe som er avgjørende for å forhindre dupliserte sideeffekter.
  • Mekanismer for nye forsøk: Strategier som eksponentiell tilbakeventing med jitter, som lar klienter håndtere forbigående feil på en kontrollert måte ved å prøve forespørsler på nytt med gradvis økende, tilfeldige forsinkelser.

Ved å kombinere idempotens med intelligent logikk for nye forsøk kan du utforme API-interaksjoner som er robuste, pålitelige og tolerante overfor den uforutsigbare naturen til distribuerte systemer.

Gratis å komme i gang

Lær deg Mønstre for API-ratebegrensning og skalerbarhet med en AI-veileder – gratis

Skriv og kjør ekte kode i nettleseren, få umiddelbar hjelp fra en AI-veileder som er tilgjengelig døgnet rundt, og fortsett der du slapp – på nettet eller i appen.

Kurs
12
Leksjoner
48

Ofte stilte spørsmål

Er leksjonen «Idempotens og mekanismer for nye forsøk» gratis?

Ja – hele teksten i «Idempotens og mekanismer for nye forsøk» er gratis å lese her på nettet. For å øve interaktivt med en innebygd kodeeditor og en AI-veileder som er tilgjengelig døgnet rundt, og for å låse opp resten av Mønstre for API-ratebegrensning og skalerbarhet-kurset, kan du oppgradere til CoddyKit PRO. Kurset i Mønstre for API-ratebegrensning og skalerbarhet inneholder totalt 4 leksjoner.

Hva lærer jeg i «Idempotens og mekanismer for nye forsøk»?

Utform idempotente API-operasjoner og implementer intelligente mekanismer for nye forsøk, slik at midlertidige feil håndteres på en kontrollert måte uten bivirkninger. Du øver på Mønstre for API-ratebegrensning og skalerbarhet med praktisk kode som du kjører direkte i nettleseren, mens en AI-veileder som er tilgjengelig døgnet rundt, svarer på spørsmålene dine mens du jobber deg gjennom leksjonen.

Trenger jeg erfaring for å begynne med Mønstre for API-ratebegrensning og skalerbarhet?

Ingen tidligere erfaring er nødvendig. Mønstre for API-ratebegrensning og skalerbarhet på CoddyKit er lagt opp for både nybegynnere og viderekomne, så De kan begynne her eller helt fra start og lære i Deres eget tempo. Dette er leksjon 2 av 4.

Hvor lang tid tar leksjonen «Idempotens og mekanismer for nye forsøk»?

De fleste CoddyKit-leksjoner tar omtrent 5–10 minutter. Hver leksjon er kort og interaktiv, slik at De gjør jevne fremskritt og kan fortsette akkurat der De slapp – både på nettet og i appen.

Kan jeg skrive og kjøre kode i denne Mønstre for API-ratebegrensning og skalerbarhet-leksjonen?

Ja. Alle Mønstre for API-ratebegrensning og skalerbarhet-leksjoner har en innebygd kodeeditor, slik at De kan skrive og kjøre ekte kode direkte i nettleseren og få umiddelbar tilbakemelding fra AI – uten lokal konfigurering.

Alle leksjonene i dette kurset

  1. Circuit breakers og bulkheads
  2. Idempotens og mekanismer for nye forsøk
  3. Geografisk distribuerte API-er og katastrofegjenoppretting
  4. Lastreduksjon basert på hastighet og mottrykk
← Tilbake til Mønstre for API-ratebegrensning og skalerbarhet