Sikre idempotens i Sagaer

I distribuerte systemer er idempotens et viktig konsept. En operasjon er idempotent hvis det å utføre den flere ganger gir samme resultat som å utføre den én gang.

• Tenk på det som å trykke på en lysbryter: Når De trykker én gang, slås lyset på (eller av). Hvis De trykker én gang til, endres ikke tilstanden ytterligere dersom lyset allerede er på (eller av).
• Dette er avgjørende fordi meldinger kan bli duplisert eller forsøkt på nytt.

Når tjenester kommuniserer, særlig asynkront via meldingsmeglere, kan meldinger noen ganger bli levert mer enn én gang. Dette kalles levering «at-least-once».

• Nettverksproblemer: En tjeneste kan sende et svar, men avsenderen mottar det ikke, noe som fører til et nytt forsøk.
• Tjenestefeil: En tjeneste krasjer etter at den har behandlet en melding, men før den har bekreftet mottaket, slik at meldingen leveres på nytt.
• Uten idempotens kan disse duplikatene føre til utilsiktede bivirkninger, som at en kunde blir belastet to ganger eller at dupliserte bestillinger opprettes.

Saga-mønsteret orkestrerer komplekse forretningstransaksjoner på tvers av flere tjenester. Hvert trinn i en saga er en operasjon som utføres av en tjeneste.

• Hvis et sagatrinn mottar den samme kommandoen eller hendelsen to ganger, kan det føre til inkonsistente data.
• Hvis for eksempel kommandoen «trekk betaling» behandles to ganger, kan kundens konto bli belastet for mye.
• Idempotens sikrer at den overordnede forretningstransaksjonen forblir korrekt, selv om en sagadeltaker mottar en melding flere ganger.

For å oppnå idempotens bruker vi ofte en idempotensnøkkel. Dette er en unik identifikator som er knyttet til en bestemt operasjon eller forespørsel.

• Nøkkelen genereres vanligvis av klienten eller tjenesten som starter operasjonen, og sendes sammen med forespørselen.
• Den gjør det mulig for den mottakende tjenesten å oppdage om den allerede har behandlet akkurat denne operasjonen.
• Dette kan for eksempel være en UUID (Universally Unique Identifier) eller en unik transaksjons-ID.

En vanlig måte å implementere idempotens på er mønsteret «sjekk-før-utførelse». Før tjenesten utfører en handling, sjekker den om operasjonen som er knyttet til idempotensnøkkelen, allerede er fullført.

Den grunnleggende logikken er:

1. Motta en forespørsel med en idempotensnøkkel.
2. Sjekk om denne nøkkelen allerede er merket som behandlet.
3. Hvis den er behandlet, returner det opprinnelige resultatet (eller suksess) uten å utføre operasjonen på nytt.
4. Hvis den ikke er behandlet, utfør operasjonen og merk deretter nøkkelen som behandlet.

La oss se på et konseptuelt Java-eksempel på en idempotent metode for betalingsbehandling. Vi bruker et enkelt sett i minnet til å holde oversikt over behandlede nøkler, selv om et ekte system ville brukt et persistent lager.

Prøv å kjøre dette eksempelet:

For operasjoner som skriver til en database, kan De ofte bruke databasefunksjoner til å håndheve idempotens:

• Unike begrensninger: Legg til en unik begrensning på kolonnen for idempotensnøkkelen (for eksempel request_id) i tabellen. Hvis en duplikatnøkkel settes inn, vil databasen generere en feil.
• Betingede oppdateringer (UPSERT): Bruk kommandoer som INSERT ... ON CONFLICT DO NOTHING (PostgreSQL) eller INSERT ... ON DUPLICATE KEY UPDATE (MySQL) for å forhindre at duplikater settes inn, eller for å oppdatere bare hvis en post finnes.

Tenk på oppretting av en bestilling. Vi vil sikre at det bare opprettes én bestilling dersom den samme forespørselen om å «opprette bestilling» sendes to ganger.

Ved å bruke en unik request_id:

-- SQL example (conceptual)
INSERT INTO orders (order_id, customer_id, amount, request_id, status)
VALUES ('ORD001', 'CUST123', 100.00, 'req-uuid-123', 'PENDING')
ON CONFLICT (request_id) DO NOTHING;

Denne setningen setter inn bestillingen hvis req-uuid-123 er ny. Hvis den allerede finnes, ignorerer databasen innsettingen, slik at idempotens sikres.

Idempotens gjelder ikke bare sagatrinn som går fremover; det er like viktig for kompenserende handlinger.

• Hvis en forespørsel om kompensering (for eksempel «refunder betaling») sendes flere ganger på grunn av nye forsøk, vil De ikke utstede flere refusjoner.
• Bruk de samme idempotensprinsippene: Bruk en unik nøkkel for kompenseringsforespørselen, og sjekk om den allerede er behandlet før den utføres.
• Dette sikrer at systemet bare reverserer den opprinnelige handlingen én gang.

For å implementere idempotens effektivt i sagaene:

• Bruk robuste unike nøkler: Generer virkelig unike ID-er som ikke er enkle å gjette (for eksempel UUID-er) for hver operasjon.
• Lagrede behandlede nøkler persistent: Ikke stol på lagring i minnet. Bruk en database eller en dedikert hurtigbuffer til å holde oversikt over behandlede nøkler.
• Håndter samtidighet: Sørg for at logikken for sjekk-før-utførelse er atomisk, slik at De unngår kappløpstilstander der to identiske forespørsler behandles samtidig. Unike begrensninger i databasen egner seg svært godt til dette.
• Definer omfanget: Definer tydelig hva som utgjør en «idempotent operasjon», og på hvilket nivå nøkkelen gjelder (for eksempel per melding eller per forretningstransaksjon).

Vi har lært at idempotens er avgjørende for å bygge robuste distribuerte systemer, særlig når Saga-mønsteret implementeres.

• Det sikrer at en operasjon gir samme resultat når den utføres flere ganger, som når den utføres én gang.
• Dette forhindrer utilsiktede bivirkninger fra dupliserte meldinger eller nye forsøk, som er vanlig i distribuerte miljøer.
• Ved å bruke idempotensnøkler og mønstre som «sjekk-før-utførelse» eller unike begrensninger i databasen kan sagadeltakere behandle meldinger trygt og opprettholde datakonsistensen.